Often, we do not choose to involve QA professionals in the requirements process until we are on the verge of producing testable code. QA engineers help create testable, high-quality requirements specifications. Getting them engaged early creates more successful projects because they have the context to plan and prepare. In this post, I’ll lay groundwork supporting “why” but also get into the critical questions of “what”, “when” and then, of course, “how.”
Why involve QA in requirements reviews?
I posed this question to the LinkedIn community and received 16 answers, most within the first day of asking. I sensed passion and a commitment to good requirements, but also that these individuals often felt left out of the early phases of the project and that this impacted the quality of their work.
Earl Everett from Autodesk earned “best answer” with the quotable comment: “The investment (or lack thereof) made in quality requirements provides the biggest ROI. You can’t *test* quality into a product, and trying to bolt it on, or graft it in afterward rarely, if ever, proves efficient, effective, or efficacious.” So, so true. If you relegate QA responsibilities to just testing the end product, you overlook an opportunity to integrate quality into the entire software development life cycle.
What, exactly, does QA do during a requirements review?
QA engineers provide feedback on requirements specifications that help business analysts resolve issues before those specs get converted to code. They help us reduce ambiguity by ensuring our requirements are testable. To quote Nirmal Chandran from John Deere, “hidden facts of requirements can be brought into focus with requirements review.”
By getting involved upfront, the QA team also has time to prepare for the actual testing. They learn about the system to be delivered and can start planning. They may need to acquire new tools or obtain training on a particular knowledge area. Definitely they can start preparing test plans, test cases, and test estimates.
When do I bring my quality assurance team in?
This is an important question. We don’t want to waste anyone’s time. QA engineers tend to be busy people and often crunched testing the latest release. Involve QA when the ambiguity is about to settle. Don’t bring in QA (or much of development for that matter) when the business is still going back in forth about what they really want. But do bring them in as soon as requirements are starting to take definition and on the verge of being actionable.
What is the best way to get QA’s input on the requirements?
I suggest having a kick-off meeting with the technical team first. Meet with your tech leads, QA lead, and anyone else involved in the creating the solution independently. Explain the context of the project at a high level. In essence, this is a “get everyone up to speed” meeting. Then bring the whole team together (business and tech) for the requirements walk-through. Let people drill the specification with questions, comments, clarifications. Encourage dialog.
You are definitely walking a line between bringing people together and working with them separately. The goal is to avoid repetition as often as possible without creating unnecessary distance between team members. Your goal should be to create a maximum amount of meaningful collaboration amongst the team members by prepping them about what’s already been covered.
Yes, so that’s it. As always, comments welcome! I’d love to hear a success story about how business analysts and quality assurance professionals collaborated together to create high quality requirements!
Update 4/16/2009: I’ve improved my opinion on this topic. Check out new posts on validating requirements: