• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Incorporating the Software Test Team into the Software Requirements Creation Process – Part 1

A lot of the popular literature, training, documentation and processes related to the management of Software Requirements in an organization are typically focused on two constituencies – Users and Developers – and thus miss an important constituency, Testers.

User is the catch-all term for anyone who may use the software being created. They typically define what the software should be able to do – they are the source of the Requirements. The Developers are the lucky ones who get to build all the wonderful stuff that the Users have asked for. They consume the Requirements; convert the concepts, ideas, rules, models and countless Requirement statements into bits and bytes of code that taken together is hopefully the solution envisioned and defined by the Requirements Analyst at the start of the process.

Sitting smack dab in the middle of this creative stream of consciousness that stretches from the User to the Developer before ending again eventually with the User is the Tester. Before the software created by the Developers is handed off to the Users, the Testers have to give it a clean bill of health. They have to certify that the Development team is giving the Users what they asked for.

How exactly do the Testers know what the Users asked for? By looking at the Requirements documents that were created at the start of the process and comparing the delivered software against the requested features and specifications.

Despite the fact that the Testers are almost entirely dependent on Requirements documentation to perform their duties, I have seldom seen them incorporated into the Requirements Creation Process. Based on my observations of multiple projects in several large multinational corporations, I have come across only one instance where the Test team was treated as a constituent group on equal footing with Users and Developers during the Requirements Creation Process.

In general, what I have seen is that Test teams have no connection with or influence over the Requirements that are given to them for testing and validation while they are being created. They are typically handed the Requirements documents long after they have been finalized and development is well underway. They are then told to ensure that the software meets the documented Requirements.

What typically ensues thereafter is chaos. The Test team comes back with a ton of questions about the Requirements that no one is able to answer. Alternately they are given multiple answers to their questions which often contradict each other. (I have often wondered which is worse, but that is the subject of another blog post.) This craziness continues until someone finally realizes that the Requirements need to be tweaked and reworked.

If the people involved with the Project were lucky, the changes made to the Requirements did not impact Development because the Developers had guessed correctly or had not yet gotten started on it. If the people involved with the Project were not lucky, the tweaks to the Requirements resulted in meaningful changes to schedule and scope since rework was needed. If the people involved with the Project were really unlucky, significant changes to scope, schedule and budget had to be made.

There are two obvious questions here. Why do the Requirements get tweaked almost always after the Test team has gotten them? And, what can we do to keep this from happening again, and again, and again, and…

Stay tuned for Part 2 and Part 3 of this series, to learn more about what we can do to avoid this waste and chaos.

2 Responses to Incorporating the Software Test Team into the Software Requirements Creation Process – Part 1

  1. Pat Gustafson January 13, 2012 at 3:52 pm #

    Maybe I’ve been lucky, but this has not happened in my experiences both as a test engineer and as a systems engineer. The telecom company I started working for right after college had testers review the feature vision documents that were used to start writing the requirements. We also reviewed the requirements, attended design reviews and code inspections. All very waterfall like. As a systems engineer I always invite the test org to any review I’m holding. Like I say, maybe I’ve been lucky.

  2. Ajay Badri January 16, 2012 at 11:02 am #

    Pat:

    Thank you very much for taking the time to read and comment. Based on what you are saying, the Test team in your organization is fully integrated with the Requirements and the Development team. If this is formalized and made standard process across the board, then all Development organizations will benefit from it.

    Most Test teams work very closely with Development teams. It is rare to see them fully integrated with the Requirements teams and that is what I am calling for.

    Thanks again for your comments.
    Ajay

Leave a Reply

Your email address will not be published. Required fields are marked *