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:
- How to align stakeholders around requirements without requirements walk-throughs
- Synthesizing, Analyzing, and Validating requirements showing the current capabilities of a process or system.
|
By Laura Brandenburg. Laura Brandenburg, CBAP, is the author of How to Start a Business Analyst Career and Professional Development for Business Analysts. Laura offers business analysis courses and consulting to people who want to get started in a business analyst career. Click here to learn more about getting started as a business analyst (it's a free email course). |
Related posts:
{ 2 comments… read them below or add one }
Hi Laura,
I totally agree with you about team interaction and how everyone’s input leads to a robust and well defined requirements. But recently in our organization, QA has been asking for a spearate kickoff just before they are ready to code and not be involved in the requirements process or the kickoff itself.
It seems QA as you said gets busy in testing current items and will not be able to focus on writing the test cases after this initial kickoff.
But my concern is with the efficiency of the BA’s and how they might have to recollect all the requirments and visit them after the kickoff for development.
I think my question is 0 Is it really a good idea to hold two kickoff – one for development and one for QA at different time frames ?
Hi Hema,
This will really depend on the priorities of your organization and how resources are allocated to projects. This fundamentally seems like a resource allocation problem. Technically I would not consider it a best practice, but there are many ways to handle this and many mitigation strategies you could pursue. And involving QA for the sake of involving QA, especially if they do not have the time to be active participants, could lead to different problems.
The thing is, that you won’t fully know the impact until you change the process. I would suggest noting the risk, discussing and implementing some risk mitigation strategies, running a pilot of the new process, and measuring the results. Then see if more requirements defects are found later in the cycle, you’ll have your answer. And, if so, what the impact of this is in terms of BA time, development time, etc. This gives the organization the information needed to make better decisions the next time around.
Some risk mitigation strategies you might consider are:
-The second kick-off, like you mention.
-Peer review of the requirements by other BAs.
-A shorter, more targeted review by QA early in the process to get their input but not take as much of their time.
Do check back and let us know how this goes!