Requirements. What do we need them for?

You all know about the concept of “requirements for requirements”. Characteristics such as completeness and unambiguity, consistency, efficiency, testability, etc. I call such “requirements for requirements” mantras, because it’s not always clear how to check them reliably.

But in software testing, any defect in terms of requirements means that you have to revise test cases, test data, automated scripts, and repeated tests. As a result, software testers are, more than any other people involved, concerned with checking those mantras.

We believe that an effective method for checking is early design of test scenarios. Maybe not even test scenarios but test conditions or test ideas – a set of high-level plans of what and for what purpose (but not how) you are going to test.

And in parallel, you start building visualized connections of test scenarios and requirements (where and what to check) which then will be transformed into a full coverage matrix.

It was believed that programmers could successfully test their own code (not only unit tests) and therefore no software testers were needed. Then everyone realized that this wasn’t so, yet the idea of doing tests without software testers has not vanished.

A new approach is to conduct tests with the help of analysts. Note, however, that testing in general and test design in particular represent separate engineering fields with their own rules and technologies. If an analyst lacks knowledge of test engineering, they won't be able to conduct tests at the required level and within the required timeframe. And it they do have such knowledge; they are software testers (which is rarely the case).

Finally, remember the defects in requirements, which testers are much more concerned to find.

In maintenance projects minor requirements cause small corrections in code but may require huge amounts of tests. Typical examples are adding a field or code refactoring, just to name a few. It means that all accepted proportions of programmers and software testers or labor efforts for development and testing can be dismissed. And here the focus should be on the adequate and justified assessment of labor efforts for testing, which only testers are able to carry out.

Earlier we mentioned building a test scenario coverage matrix. Since changes may occur (and do actually occur) in all projects, building a coverage matrix is a mandatory activity in the software testing process.

The coverage matrix enables you to get answers to the following questions:

• Which test scenarios should be used to check a specific requirement?
• Which requirements are checked by a concrete test scenario?

The need to answer the first question arises when you assess labor efforts for testing requirement changes. The need to answer the second question arises when you assess the criticality of software defects found through running a test scenario.

Requirement related risks of testing

The most common risks in software testing due to imperfect requirements are the following:

• A low quality of requirements when the tests start, which prevent you from developing and applying high-quality test scenarios
• Delayed commencement of test activities, which may prevent you from respecting deadlines and budget requirements
• Absence of or a late implementation of a high-quality review of requirements, which prevents you from performing all test activities within the required quality
• Ignoring the test scenario coverage matrix for requirements (for example, omission of some requirements is found by chance)

Come learn with us!