Most of the focus in managing software requirements has centered on Users and Developers. It seems obvious to do so, doesn’t it? Users are the ones who will use the project, may also be the ones asking for the project, and thus are typically the ones we focus on in requirements elicitation processes. Developers take those requirements; transform the concepts, rules, models, and statements into code; and produce a solution that hopefully does what was defined at the start of the project.
I have heard from our requirements architects and practitioners there is an element missing in this focus, one that is intrinsic to the success of the project: the QA and Testing Teams. Those are the people who, using the requirements, assess whether or not the Developers have delivered what the requirements specified. They are usually given the requirements as they begin their test process, and only rarely are they included earlier in the requirements process.
Why should you involve the QA and Testing Teams earlier in the software requirements process? Here are 5 good reasons, learned through painful project experience:
- Doing so will greatly reduce the time QA spends asking the Business Analysts and Developers “what does this mean?” questions about the requirements, likely leading to tweaking the requirements after Development has done significant work.
- It can reduce the time Development will spend on rework, If the requirements do end up being tweaked.
- By familiarizing QA and Testing Teams with requirements earlier, there is a better chance that requirements will be clear and consistent. QA often will find ambiguities in the requirements documents, which then can be sent back to Users for clarification.
- QA can contribute ideas to ensure requirements will be testable, by suggesting evaluation criteria for each requirement. This way, the whole team has a mechanism by which they can test whether or not the requirements are indeed complete, accurate, and clear.
- Improve the outcomes from testing, by reducing the chances that software will pass QA tests and yet won’t meet the requirements. How is that even possible? Imagine this: the Business Analyst team provides requirements; Developers read—and think they understand—the requirements. The Developers write some tests and code the features; QA tests the features, which pass the tests. Then the solution is presented to the Business Analyst team, at which point the solution is discovered to be incorrect due to requirements ambiguities and misinterpretation.
If you have more (or better) reasons than my five, or if you think including QA and Testing earlier in the requirements process will cause problems, please leave a comment and let me know.