Should test cases be directly linked to requirements?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
This is a question that depends greatly on the context of your environment and type of systems you are working on.
Generally, I find knowing the documented requirements to be a good start to creating reasonable test cases and doing good testing. What I find more important is an understanding of the business needs that the system is to address. The question around requirements is part of understanding what the business actually needs.
Unfortunately, we sometimes have a hard time identifying what the requirements actually are, as opposed to understanding the documented requirements. It is all too easy for documented requirements to be misinterpreted or misunderstood. We can challenge the documented requirements before we begin any test effort, including creating test cases.
Instead of saying test cases must (or should) be “directly linked to requirements,” I prefer to think of it as using the documented requirements to inform our test case creation. Some processes and methodologies suggest that one “documented requirement” should produce one test case. I believe that is short-sighted and limiting.
I prefer to prepare test cases around the documented requirements to test not only what is stated, but what is not stated. Thus, it is not only probable but inevitable that there will be far more test cases than documented requirements. Further, depending on context, test scenarios may overlap multiple requirements.
The danger for many testers is in using a process that demands completely documented requirements before test case definition and testing can begin. It is a rare environment that fosters that happening. Typically, I find it more likely that the true requirements will be discovered in the design and development processes. Sometimes they will not be fully understood until testing is underway.
We can only overcome these deficiencies with a good understanding of the business intent: the purpose of the system or the change being made. With these, we can then judge the efficacy, accuracy and completeness of the requirements, which in turn, can assist us developing test cases and performing effective testing.
Dig Deeper on Gathering Software Requirements Use Cases
Related Q&A from Peter Walen
Veteran software quality pro Peter Walen explains what software tester skills are really necessary in today's enterprise organizations.continue reading
Software testing veteran Peter Walen explains how software testers can write test scripts that others can follow without having to test by rote.continue reading
Crowd sourcing can be a key piece of a test strategy for enterprise mobile apps aimed at customers, not employees.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.