Page 225 -

208 Chapter 8 Software testing

Inspections

Requirements Software UML Design Database
Specification Architecture Models Schemas Program

System
Prototype Testing

failures because the benefits of use outweigh the costs of failure recovery.
Figure 8.2 Inspections
and testing In these situations, you may not need to devote as much time to testing the soft-
ware. However, as software matures, users expect it to become more reliable so
more thorough testing of later versions may be required.

3. Marketing environment When a system is marketed, the sellers of the system
must take into account competing products, the price that customers are willing
to pay for a system, and the required schedule for delivering that system. In a
competitive environment, a software company may decide to release a program
before it has been fully tested and debugged because they want to be the first
into the market. If a software product is very cheap, users may be willing to tol-
erate a lower level of reliability.

As well as software testing, the verification and validation process may involve
software inspections and reviews. Inspections and reviews analyze and check the
system requirements, design models, the program source code, and even proposed
system tests. These are so-called ‘static’ V & V techniques in which you don’t need
to execute the software to verify it. Figure 8.2 shows that software inspections and
testing support V & V at different stages in the software process. The arrows indicate
the stages in the process where the techniques may be used.
Inspections mostly focus on the source code of a system but any readable repre-
sentation of the software, such as its requirements or a design model, can be
inspected. When you inspect a system, you use knowledge of the system, its applica-
tion domain, and the programming or modeling language to discover errors.
There are three advantages of software inspection over testing:

1. During testing, errors can mask (hide) other errors. When an error leads to
unexpected outputs, you can never be sure if later output anomalies are due to
a new error or are side effects of the original error. Because inspection is a
static process, you don’t have to be concerned with interactions between
errors. Consequently, a single inspection session can discover many errors in a
system.