Q

What is the link between test cases and requirements?

Expert Pete Walen describes the intricacies of the relationship between requirements and test cases, explaining how the context and the realities of the requirements make a difference in how test cases are produced.

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

Dig deeper on Gathering Software Requirements Use Cases

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close