 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Software Quality News > Five agile testing perils to watch out for |
| |
|
|
|
|
| Software Quality News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ORLANDO -- Your development group has adopted an agile method, which involves more testing on the part of programmers. That does not mean, however, that software testers are out of their jobs. It means that testers need to adjust and learn to test differently.
Of particular importance is the need to test user stories, said Janet Gregory, a consultant with DragonFire Inc. "A story is not done until it's tested," she said. During her session "Perils and Pitfalls of the New Agile Tester" at the STAREAST Conference and Testing Expo, Gregory explained what's expected of agile testers. She also outlined perils testers often face, the risks of such perils and how to avoid them. As an agile tester, you are expected to test without having formal requirement documents, to test in real time, to test changing code, to test on changing requirements, to automate most of your tests and to be a part of a close-knit team. As you strive to meet those expectations, you may struggle and have to deal with what Gregory calls the perils of agile testing. Peril 1: Waiting for Tuesday's build
The hazards of not testing regularly include stories not being tested, testers losing credibility, velocity becoming affected, and feedback from the stakeholders not coming fast enough. In addition, bugs aren't discovered until the programmers move on to the next story and "testing runs into the end game," Gregory said. The most important thing you can do to avoid this peril is to be proactive, she continued. Work with the "build master" to get regular builds and plan for your test infrastructure. You should also test immediately, test on the programmer's machine if possible (pair testing), include testing tasks in velocity planning, and get programmers used to getting feedback. There should be a balance of testing with coding, Gregory said. "Trying to go faster and harder won't work," she said. "You want to work [at] the same speed and effort at the programmers." Peril 2: You're not really part of the team The risks of working this way include the following:
To prevent this from happening, you need to push the "whole team" attitude, Gregory said. Sit with or near the programmers so that it's easier to talk with them, invite yourself to meetings, make sure someone from all three groups is present when discussing stories, and ask to "just try" new ideas for an iteration or two. You need to understand your role as a tester and be useful. Constantly test and provide feedback, Gregory said. Peril 3: Maintaining a "Quality Police" mindset
However, in agile development, the whole team is responsible for quality, not just the testers. If the whole team doesn't buy into building quality in, then the programmers use the testers as safety nets, communication is done only through the bug-tracking system, and the team never "jells," Gregory said. Again, it takes initiative on the part of testers to overcome this. Testers need to develop relationships with programmers, show how each role adds value and try to get the whole team to own the quality of the product, she said. Testers can lend their expertise to programmers, ensure that testing happens during an iteration, and define what "done" means up front with the whole team. And for tracking bugs, try using index cards. Put the cards on the wall for bugs found in stories. Peril 4: Trying to test everything manually Not automating your tests will lead to bugs creeping in and the inability to keep up with new stories. In addition, features that used to work and are broken aren't noticed, and testers get stuck in a rut and don't learn new things. Gregory suggests you do the following:
Peril 5: Forgetting the big picture If that's the case, your stories don't connect, pieces of the puzzle don't fit, your workflow isn't smooth and decisions made during coding aren't aligned with the end goal. "You risk not building the correct thing," Gregory said. You can avoid this by building acceptance tests first, using business-facing test to help drive development, thinking about the impact to other parts of the system, finding a way to build test data that reflects the real world, and understanding the story before coding starts. Other techniques you can use include the following:
These perils may seem daunting, but they are manageable. New teams, however, may want to use an agile coach to help identify and deal with them. Gregory also suggests participating in Yahoo's agile testing group and reading articles. "Agile testing is full of perils," she said. "Be aware of them and watch for them, but don't let them scare you."
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
