How important is it to the testing process that requirements be managed properly? In what ways can team members gather and manage requirements that could facilitate testing?
These two questions represent a fair part of the question around the tester’s role in determining requirements. And that is one of the fairly common topics at conferences on software quality and testing.
There are a couple of ideas that work together around testers and software requirements. One is that the single most important thing testers can do for a project is to ask questions. Test the requirements. In the process of this, look for gaps and inconsistencies, just like you do when testing the application itself. Then after the requirements are “done” keep revisiting them. As changes are introduced (let’s face it, requirements are likely to change as the project team learns more about the actual project and the user needs) these modified and added requirements can be tested just as the original requirements were.
Staying on top of these changes as the team learns more is crucial, no matter what methodology or approach is in use. These developing requirements can sometimes give clues to the test team for areas to test more aggressively than others.
To what end?
We’ve heard that testers need “testable requirements,” yes? If all we can bring to the table as testers is demanding “testable requirements,” we are missing a huge opportunity. Remember the questions I mentioned before? That is what we can bring to the table, the value we can add to the project team.
By asking questions and clarifying questions around the requirements, we can help all the participants gain an understanding around our thinking. This can lead to greater discussion among other members of the project team and possibly avoid problems resulting from assumptions before they become problems.
For testers, by participating in these conversations, not just observing or reading summary notes, we can likewise gain insight into the thinking of the rest of the project team and look to examine expectations and beliefs of the user representatives and the development group. This can help us plan our testing from this living understanding of the requirement definitions, instead of a static understanding simply from the written record.
This was first published in May 2012