By Michelle Davidson
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.
Agile testing is full of perils. Be aware of them and watch for them, but don't let them scare you.
Janet Gregory
Consultant, DragonFire Inc.
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
With agile development, you need to test constantly, Gregory said. You cannot wait until the end of a build. How do you know you're in this predicament?
• Stories stack up in "To Test"
• Stories aren't tested in the same iteration
• Deploys aren't tested regularly
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
You'll know if this is a problem if testers aren't invited to planning sessions, if testers don't talk during meetings, if the business users define the stories by themselves and if testers don't understand the stories.
The risks of working this way include the following:
• Assumptions are not uncovered early
• Impacts to the system are found late
• People aren't using their time and skills well
• You don't know what's going on
• The team becomes divided
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
Chances are you've worked in an environment where the Quality Police run things. There's a separate test team that sits apart from the rest of the development team, all of the bugs are put into a defect-tracking system and the test team can stop production.
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
If you try to test everything manually, you will not be able to keep up with the programmers, Gregory said. You'll know this is a problem if you spend time retesting features, don't test new features, need more and more testers and don't contribute to implementation and design discussions.
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:
• Use automation to build your regression suite
• Design for testability
• Automate as you go (get programmers involved)
• Help programmers write good unit tests
• Find an automation tool that works for the whole team
• Show your skills
• Expand your toolkit
Peril 5: Forgetting the big picture
In agile development, you need to see the entire forest, not just the trees in front of you. You'll know that you aren't considering the big picture when you end up testing only individual stories, find integration bugs late in the release, don't develop reports until the end, all of your tests are based on what the programmer tells you and you do only exploratory testing.
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:
• Use whiteboards to draw pictures
• Think about workflows
• Use exploratory testing
• Use examples
• Build acceptance tests first
• Have programmers refuse to code without tests
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."
Please refer to User Stories: _http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci1306778,00.html
No comments:
Post a Comment