This is the last post in a series on “why incorporate the test team into software requirements creation earlier” – for the first post, click here; for the second post, click here.

In the first part of this series on the role Testers can and should play in the requirements creation process, I stated that I had seen only one instance where the Test Team was treated as a constituent group on equal footing with Users and Developers. Coincidentally, this was also one of the most successful projects I have worked on to date. I’ll share the lessons learned here, and show you how implementing a similar process in your organization will result in better requirements and better project outcomes.

First off, we arrived at our final process only after we had suffered through the pain I described in Part 1 and Part 2 of this series. (And leaving the Test Team out of the Requirements process resulted in a lot of pain.) The client’s firm was very much a conventional organization, with conventional processes around requirements creation:

1. The Users defined the problem space, objectives, features and desired outcomes.
2. The Business Analysts facilitated this process and documented their needs.

The Analysts’ documentations were then fleshed out in greater detail, made into formal requirements, and were then handed off to the Development team. The only ones who saw the requirements documents and signed off on them were the Users and Developers. The Test Team were provided the requirements documents once we were well into development.

This was the cue for chaos to ensue during every single release, as requirements were questioned, clarified, modified, reworked, eliminated, added, split out, and generally massaged until the Test Team finally said the requirements made sense. This chaos was accompanied by the usual hand-wringing and stress that can be expected when that much rework and modification happens. 

After a couple of iterations of this, we decided we had enough and decided to do something about the process. The solution was obvious – incorporate the Test Team into the requirements creation process. The only question was when in the process would they be involved, and what specific contributions were expected of them.

After a bit of trial and error this is what the reworked process looked like:

1. Once the high level Feature planning for a Release had been completed (or a good solid first pass nailed down by way of Features and Functionality being targeted), we immediately shared it with the Test Team. They really did not have any input into specific features or requirements at this stage other than to raise concerns around testing resources, such as if test platforms needed to be upgraded or special software purchased to enable the new features to be tested properly. (While all of these are very valuable from a project planning perspective, they really do not impact the requirements per se.)
2. The targeted features were fleshed out in greater detail and a Business Requirements Document (BRD) was created, and the Test Team was included as a reviewer, but not as an approver, for this document. At this stage, the features were still defined at a higher level and not typically at a level of specificity sufficient for test case creation. The Test Team kept a sharp lookout for non-functional requirements in the areas of security, access rights and performance in these documents.  They alerted us to missing functionality up front, and also frequently gave us a sanity check on some of the performance type requests. I often consulted with them while defining these features, since the Test Team’s input was extremely knowledgeable and pragmatic.
3. Once the BRD was approved, we fleshed it out in greater detail and created a System Requirements Specification (SRS) document, containing the detailed requirements that would be handed off to Development; it was also the document that the Test Team used to create their test cases. The Test Team was given approval rights on all these documents. Simply put, if they did not sign off on the document, it could not be formally handed off to Development. The Test Team also had veto power. This simple change resulted in a dramatic improvement in the quality of the final requirements. From the very first release where the Test Team was given this authority, ambiguous or untestable requirements were practically eliminated; the quality of the non-functional requirements also showed significant improvement.

The first time we implemented this process, the requirements delivery slipped schedule by a couple of weeks: this was how long it took us to clean up the documentation. Once that was done, however, the rest of the process went smoothly. Further, subsequent releases saw much better documentation up-front, and a lot of sloppiness had been wrung out of the entire process.

Regardless which development methodology your organization favors, if you use Test Teams for software testing and QA, I am positive that including them as part of your requirements creation process will result in significant improvements in the quality of requirements documentation produced by your team, and ultimately in the quality of and reduced rework for the project as a whole.