Testing is traditionally done when some of the software has been built. That is, the testers test the delivered code to determine that it is working correctly. Nontraditionally, some organizations distribute their testing activities throughout the life cycle. In particular, they introduce testing during the earliest stages of product development (long before anything tangible like software is produced), and early in each iteration. Early testing—that is, testing before testing—is done to ensure the project’s proposed deliverables can be tested for correctness once they have been produced.
The justification for pre-test testing is that it makes later testing far more productive and, along the way, significantly reduces the amount of time spent correcting avoidable errors. Organizations that use early testing find that later efforts can be safely restricted to testing whether or not the product is working as desired. Many organizations can’t do this, because they have little confidence that their definition of “working as desired” is correct. If the requirements themselves have not been tested, then they cannot be trusted by the software testers. The idea of early testing is to provide the later-stage testing with an accurate yardstick against which to measure the solution.
But early testing is not restricted to requirements; it works for any project deliverable. For example, the design of a product can be tested early provided it is communicated in some tangible form. Similarly for the project plans, the scope document, and so on, through the project deliverables. All of these can benefit from early testing when they are presented in a testable form. Additionally, the expectation of early testing influences the producers and results in interim deliverables that are more widely comprehensible.
Belated testing—delaying testing to a time when the product has already been built—cannot help the success of the project. By that stage, if errors exist—and if there is no early testing, they will almost certainly exist—it is too late.
Testing before testing means introducing quality control at the time of the initial project discussions. On projects that do this, the earliest deliverables are tested to see if they make sense before proceeding. The point of this early testing is to uncover as many misconceptions, misunderstandings, conflicts, unrealistic expectations, and so on, as early as possible—before they become entrenched and difficult to dislodge. Testing before testing means you are testing the highest-impact deliverables, which naturally gives you the best return on your testing effort.
Peter Hruschka teaches this IREB Advanced Level Module. Contact CONECT for details.
The preparation course for the IREB "Certified Professional for Requirements Engineering" is now available as video training. Learn at home or any other place. Including questionnaires to prepare you for the multiple choice test.
A Sci-Fi novel from Tom DeMarco: Andronescu’s Paradox. Could this be the Apocalypse we’ve all been dreading? Or has the nineteenth century just returned for an encore? Click to find out.
In a recent issue of IEEE Software Tom DeMarco asserts that “All Late Projects Are the Same.” Do you agree with Tom or not? Take a look at All Late Projects Are the Same.
Suzanne Robertson was interviewed by Penny Pullan on the subject of 'The Business Analyst Working with the Project Manager'. This interview is part of the Business Analysis Summit, November 2011. Listen to the interview at volere.co.uk.