Should test cases be directly linked to requirements?
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.
This was first published in May 2012