This is the second post in a series on “why incorporate the test team into software requirements creation earlier” – for the first post, click here.
The downsides to not integrating the Test organization into the requirements creation process are rework, schedule slippage, scope changes and budget overruns. Bringing the Test team into the picture much later in the Development cycle almost always leads to the requirements being reworked. Why is this so?
I have found four main reasons for this:
- Poorly written Requirements
- Untestable Requirements
- Missing or Improper Non-Functional Requirements
- Testers look at Requirements from a different viewpoint than Users and Developers
Let us look at each of the above in a bit more detail.
Poorly written requirements are typically ambiguous or complex. For example, “System shall be scalable.” No one wants an application that cannot scale. So the Users demand it, the Analyst records it, and the Developers sign off on it because they believe that anything they build will scale infinitely. But the moment a Tester gets this requirement, they will likely start asking questions. “What do you mean by scalable? How many users? How many transactions? What hours of the day?”
These are all valid questions that should have been addressed during the requirements creation process, but unfortunately were overlooked. Time to go back to the drawing board…
Untestable requirements do not have enough clarity and specificity for a Tester to write valid test cases against. I have seen this manifested in a couple of ways. First are the ambiguous requirements described above and the problems they cause. Another manifestation of this are lazily written requirements that typically refer to other documents or sources of information which contain the actual requirements or business rules. For example, “System shall comply with Fed E regulations.” This innocuous statement will be accompanied by a pointer to a reference document in an Appendix that when opened will contain about 500 pages of dense legalese, some of which are the “Fed E” regulations near and dear to the User’s heart. It is all there somewhere.
The User may know where it is and what it means. Neither the Analyst nor the User wanted to spend the time to extract the relevant pieces and document them, so, with a lazy wink and a nod, they sent it downstream.
The Developer will likely take a swipe at it, and hopefully get it right – but if they don’t get it right, it’s time for painful rework. This wasteful laziness on the part of the User and Analyst would have been stopped by a Tester who has to write concrete test cases, who then would quickly come to the conclusion that it is impossible to do so with the information provided.
In my opinion, writing good non-functional requirements is one of the most difficult skills for an Analyst to master. Testers quickly identify the holes and gaps in the requirements – gaps that everyone else overlooked – and Testers are especially useful in finding holes in non-functional requirements, such as security and performance. So incorporate your Test and QA Teams earlier, to avoid waste and rework!
Testers look at the requirements in a way that is fundamentally different from a User or a Developer. Users are really not trained to know a testable or unambiguous requirement, and do not care to know. They paint a picture for the Requirements Analyst and rely on the Analysts’ expertise to create good requirements documents. As long as they believe that the essence of what they are asking for is conveyed, they are happy. Developers are typically anxious to get started and write code. As long as they believe they have enough information to create a solution, they are happy. Although I might sound heretical, the fewer the details and constraints on a Developer, the happier they are.
In contrast, Testers look for details and specifics. They use the requirements to write test cases. If the requirements are vague, ambiguous, or are otherwise lacking in details and specifics, they simply cannot write test cases. Without test cases, they cannot tell us with any degree of confidence whether the delivered application complies with the requirements or not.
And this is, of course, the primary job of QA and Testers. So Testers have no choice but to force the issue and demand clear requirements, without which they cannot function. Without Testers demanding clear requirements and sending Users and Analysts back to the drawing board, lots of Developer time and resources will have been wasted.
In the last post in this series, I will show you how to use the Test Team correctly, making them an integral part of the requirements creation process. Testers and QA will help you get good clean requirements that eliminate rework, reduce those nasty downside surprises with schedules/budgets, and keep Users and Analysts from going back to the drawing board.
