We had a question come in during one of our webinars on test cases and thought it deserved more thought than a simple answer within the webinar itself. The question was, “In reference to writing unit tests for requirements, requirements should be testable, but why not write the test when you write the requirement. Is that over bearing?”

You may think this is the crux of requirements-based testing. Yet requirements-based testing is actually a formal term that involves not only testing the software based on requirements, but testing the requirements themselves or making sure the requirements are complete and unambiguous. Additional ambiguity can be derived now that with Agile methodologies, sometimes requirements are seen as user stories. 

If a tester was to write a requirement, it would be easy. We’d write the requirements in a way that they would be directly testable. The problem is that most requirements are written by business analysts, product owners, or product marketers who don’t think quite like testers do. Sometimes they think like end users or about a need or function, but not through all the details, such as what types of users would do what with the function, and what other things they might do that are not expected. This means that most of the time requirements are not clear or concise enough to not be directly testable. As testers, we’d like to think we should write the requirements ourselves. But those other contributors are needed, as they usually have a great domain knowledge, awareness of competitor products, and deeper understanding of the end users and customers.

To make requirements testable,  it’s important to have a clear understanding of what the requirement is about, who it is for (what user), and how the user will actually utilize the function. Once we figure that out, we can write specific instances of the requirement via scenarios, or user stories. With these more specific instances, we can then write test cases.

So the final answer to the question is YES, you can write a test for a requirement, but there are usually many steps before that. The reason is that in general, requirements are not specific enough to directly generate a test case. The end result will be many test cases based on a single requirement.

Regarding “requirements should be testable,” yes they should be, and you need to first develop all of the most likely use cases for the requirement and then write test cases for those. “Writing unit tests for requirements” is usually not done in the whole, but rather for specific instances of the requirement that are implemented, and usually by developers testing their own code.