Software testers moving waterfall development environments to the agile development model don't have to be driven to the head-banging stage of frustration. Actually, if pointed in the right direction, they'll probably like the collaborative, customer-focused, lighter-on-documentation world of agile.
Here are the best practices I've used for guiding the waterfall software testing veteran through agile development toward the goal of premium software quality.
Taming coding cowboys
There's no room for any cowboy coding practices in either agile or waterfall methodologies. Testers must buy into and be involved in project collaboration with the rest of the agile team. Testing must involve collaboration -- not submission -- at each step of the iterative process. The iterative testing receives the focus with each step of the process in order to minimize the risk of issues in a future step, which could then chain-react into back-stepping through the process.
Answer these two easy questions, and you'll find out if testing is aligned with the agile team:
1. Is a team member formally assigned to the testing? If the actual testing is built into other functions -- for example, business users or developers -- is there a formal process to ensure testing has been signed off on?
2. Is the testing being carried out in the same iteration as the coding? If the testing is slipping an iteration or two behind, then basic collaboration is not working and must be revisited.
Including testers in development
The need to include testers should be obvious from the first question above; however, it requires additional focus for testers or organizations used to the waterfall method.
For testers that are comfortable with the waterfall method, including them much earlier in the process will seem much too early for them; however, by including them early on, the testers will gain a better understanding of the a...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
gile methodology and can immediately start determining appropriate levels of testing.
Ask these two questions to ensure you are including testing in your agile project:
1. Does the tester have the same access to team activities, portals and documentation as other team members? If not, is there truly a need for them not to have access to the information? (For example, a business user performing testing does not need access to source code; however, there is likely no reason not to allow access to technical requirements, even though traditionally, such access would not be provided.)
2. Is testing part of the normal flow of activity and built into team communications? Tabling issues identified while testing is a true sign that the tester and/or testing is not being included appropriately. For example, if a test has shown issues with an application's GUI, it should be appropriate for it to be identified and discussed when discussing the GUI.
Including customers in testing
Traditionally, formal testers are responsible for identifying issues before customer testing and acceptance to ensure requirements and functionality work as required. Even if formal testers are not assigned to the project, testing will tend to emphasize catching it before the customer. Under the agile methods, the customer is included as part of the process, so little effort can be wasted identifying issues before the customer views the results. These simple questions can be asked to ensure the customer is included in testing:
1. Did the customer receive an overview of testing objectives and standards and have an opportunity to add objectives?
2. Does the customer have the same access to testing results as other teammates?
3. If testing is distributed among teammates, were customer teammates assigned formal responsibilities like others?
The documentation and collateral question: Less is more
Due to the continual face-to-face communications typical in agile development, testing, like other aspects of the project, must answer the question of how much data related to documentation and testing is necessary to ensure adequate testing, as there simply isn't a good alignment with the waterfall methodology.
To determine the appropriate level of documentation, the sophistication of the application must be considered; however, an understanding of agile methods and teams' typical strengths and weaknesses when performing testing are equally important. Generally, documentation should be used for the following scenarios:
1. People hate repetition and will skip it. If an application has 50 fields to complete and testing needs to happen across the 50 fields from a formatting and calculations perspective, a checklist is likely most appropriate, to afford checks and balances in something that is easily skipped on the next iteration.
2. Complicated algorithms are often forgotten. If the team spends a lot of time hashing through a particular algorithm, then testing the algorithm will most likely also need to be thorough; this thoroughness will most likely require documenting, or the team will find itself continuously revisiting the algorithm.
Also, identifying what is not necessary can be key for including testers that have waterfall experience and may tend to create more documentation than necessary under agile methods. The following should be considered common targets:
1. Avoid separate testing portals, websites, testing instances, document repositories, etc., where the team is receiving no other value than testing. For example, a test instance can be very useful to ensure a focus on the particular iteration; however, just pushing code there because that is how it functions under waterfall methods, when it isn't being used by the team, is a waste of resources.
2. Watch out for one-time documents. One-time documents can be key to documenting sophisticated design challenges and become a reference. For testing, there are generally very few circumstances requiring one-time documents. Under the waterfall method, they are quite useful for seeking approval and moving to the next step, but they provide very little value to a team that is working closely on a project.
3. Large manual testing sets aren't a good sign, either. If testing has to create large manual sets of testing data, then the team is most likely not working collaboratively, or the team would be looking at automated methods of creating the test set and testing it. In the waterfall method a tester may not be afforded development resources; in agile development the testing is part of the process, so the team should be working on the issue together.
Good testing is good testing, and most of the same skills are used in waterfall and agile development models. For software testers, there are many advantages to working in the agile model, ranging from greater inclusion in the development team to speedier completion of projects. I trust that these best practices will help managers and software testers make the transition with ease.
About the author: Ronald McCarty is a freelance writer and consultant specializing in systems, networks and information security. He received his bachelor's degree in computer and information systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany, and his master's degree in management with a specialization in information technology at Capella University. Ron's company, Your Net Guard, offers IT consulting and integration services in the Dallas/Forth Worth area.
