Requirements – what are they for?
It would seem that requirements are the responsibility of analysts, not testers.
But let’s go in order.
How do you check requirements testing?
Well known “requirements requirements” – completeness, unambiguity. Consistency, efficiency, testability, etc. I call such “requirements to requirements” mantras, because it is far from always clear how to test them reliably.
However, for testing, any defect in requirements means redoing test scripts, test data, automated scripts, and retesting. Therefore, testing expertise is more interested in verifying these mantras than any other expertise.
We think that an effective way to verify is to design test scripts early on. Maybe not even test scripts, but test conditions or test ideas – a set of high-level ideas of what and why (but not how) to test.
And in parallel begin to build a visualization of the relationship of test scenarios and requirements and requirements (where and what is tested), which will later be converted into a full coverage matrix.
Requirements and testing without test cases and/or without testers
It used to be believed that programmers could successfully test their own code (not only unit testing is meant), so there was no need for testers. Later it was realized that this was not true, but the idea to do without testers still exists.
The new approach is testing with the help of analysts. Note, however, that testing in general and test-design in particular is its own engineering field with its own rules and technologies. If an analyst is not proficient in test engineering, he or she will not be able to perform testing at the required level and within the required timeframe. But if he is proficient in this engineering, he is a tester (though it happens very rarely).
Finally, let us remember about defects of requirements, in finding which testers are extremely interested. So, analysts will search for them themselves? It reminds of the situation with programmers who test their own code. The success of such an activity is doubtful.
Requirements and testing in maintenance projects
The peculiarity of maintenance projects in particular is that small demands cause small code revisions but may require large amounts of testing. Typical examples are field additions, code refactoring, etc. This means that all the accepted proportions concerning the ratio of programmers and testers, or labor costs for development and testing can be broken. Here we focus on an adequate and reasonable estimate of labor costs for testing, which only testers know how to do.
Requirements and changes
Above we mentioned the construction of a matrix of requirements coverage by test scenarios. Since all projects may undergo (and actually do undergo) changes, building and updating of the coverage matrix is an obligatory activity of the testing process.
The coverage matrix allows to quickly get answers to the following questions:
- What test scenarios are testing a particular requirement?
- What requirements does a particular test scenario test?
The need to answer the first question arises when estimating the labor costs for testing a change in the requirement. The need to answer the second question arises when assessing the criticality of a defect found by running a test scenario.
Requirements Related Testing Risks
The most common testing risks due to imperfect requirements are:
- Poor quality of requirements by the time testing begins, preventing the development and application of quality test scenarios
- Late start of testing activities, not allowing you to meet testing deadlines and budgets
- Absence or untimely execution of a quality requirements review, not allowing all testing activities to be executed with the required quality
- Neglect of the requirements coverage matrix by test scenarios (for example, omission of part of the requirements is revealed by accident)