Hopefully no one questions the need for testing to be involved in the requirements definition process. But what should that look like? In a large number of companies I’ve worked with, requirements get tossed over the wall to development and testing – perhaps with some discussion between the requirements team and the development team, but not much with the testing team. I’d like to share some suggestions on how the test team can improve requirements and increase the speed to production.

Validation

Requirements validation is a process whereby various groups sign-off on the requirements and essentially state – “Yes, this is what we want/agree to build.” Typically people think of validating requirements with the business representatives/stakeholders – but really validation should be performed with all project groups, including development and test. The test team should examine each requirement for the following:

  • Are the requirements testable? Look for those “system shall be available 99.99% of the year” and other non-testable statements.
  • Are the requirements complete? Are there obvious conditions/flows the system could reach that are not detailed? Testers are particularly good at finding these kinds of misses.
  • Are the requirements internally consistent? Are there requirements that conflict with each other?
  • Are the requirements traceable? Any SRS that you receive that you can’t build a testing traceability matrix from should be sent back for re-work.

Some of the better managed organizations I’ve seen have at least one person from the test team involved during the requirements gathering process itself, not just at the end. This way, they can help steer the direction requirements take to make sure those items above get addressed properly.

Another item that the test team should provide feedback is on the overall testability of the requirements. Yes, requirements should be testable – but what if a certain requirement can be verified, but testing it is beyond the current capabilities of the test team? For example, a requirement may necessitate an automated test tool that the team does not have. Does this mean that the requirement should be stricken? Or raised to Project Management/PMO as an issue? Or kept as is, but with a disclaimer? It depends on how your organization works. By the way, there’s an interesting discussion on Seilevel’s message board on this particular topic.

Education

Another way that testing should be involved in requirements is on-going education. This is a bit different than validation, which is specific to a given project. Education deals with on-going efforts to improve the deliverables from the requirements process. Ideas to consider include:

  • Presentations/brown bag lunches/training on how to write testable requirements (chances are you’ll find that this is the biggest problem with the requirements deliverables).
  • Sharing information about the current test team’s capabilities (e.g. demoing any test tools that are available). Pointing out any gaps that exist can also be helpful.
  • “Get to Know Your Test Team” activities. Look for opportunities to build relationships – it’s much easier to negotiate with people that know rather than strangers.
  • Share problems and successes. What kinds of repeating issues are there with requirements? What things are going well?

Hopefully this post has given you food for thought. Remember, it’s a lot easier to fix issues with requirements than it is to deal with defects in the software, so make sure to take some time to address the items I’ve highlighted.