Letters to the Editors: Testing in Scrum
By SD Times News Team
July 1, 2008 —
(Page 1 of 2)
Related Search Term(s): Testing & QA, virtualization, Microsoft, Yahoo
I have read several articles in Software Test & Performance (an SD Times sister publication) about testing in Scrum or other agile software development approaches, and every one of them gives the misimpression that agile software has no documentation of the requirements. Therefore, the testers must test for what the developers say the software should do, which is a moving target.
This misconception would, of course, lead to chaos and lots of rework, especially given the rate that requirements change in agile software development. The way to make testers effective in agile software development is quite simple:
1. When the developers “negotiate” the requirements for the upcoming iteration with the customers, the testers must be full participants in those conversations. This includes asking clarifying questions, noting where requirements are untestable and pointing out other gotchas that experienced testers will see.
2. The testers immediately translate the requirements that are agreed upon in those conversations into test cases. Those test cases serve as the requirements documentation for the upcoming iteration. As soon as possible, the testers and developers collaborate in automating those test cases.
3. When requirements change, testers are immediately involved because everyone knows that the test cases must be changed accordingly.
Note that having business analysts (BA) document the requirements in ambiguous text, and then testers translating them into test cases (usually after the software has already been developed), is wasteful and leads to arguments about different interpretations of the textual requirements.
Going straight to unambiguous test cases avoids the extra step and finger-pointing. It does mean that testers should learn some BA skills. This can be accelerated by retraining some of the BAs to be testers.
Proactive participation by testers resolves the problems:
• Communication is three-way, not one-way.
• Requirements are documented as test cases (and everyone now knows what the software delivered by the end of the iteration is supposed to deliver).
• Testers are first-class team members contributing throughout the process, not second-class members playing catch-up at the back end).