Page 226 -

Chapter 8 Software testing 209

Test planning

Test planning is concerned with scheduling and resourcing all of the activities in the testing process. It involves
defining the testing process, taking into account the people and the time available. Usually, a test plan will be
created, which defines what is to be tested, the predicted testing schedule, and how tests will be recorded. For
critical systems, the test plan may also include details of the tests to be run on the software.
http://www.SoftwareEngineering-9.com/Web/Testing/Planning.html

2. Incomplete versions of a system can be inspected without additional costs. If
a program is incomplete, then you need to develop specialized test harnesses
to test the parts that are available. This obviously adds to the system develop-
ment costs.

3. As well as searching for program defects, an inspection can also consider
broader quality attributes of a program, such as compliance with standards,
portability, and maintainability. You can look for inefficiencies, inappropriate
algorithms, and poor programming style that could make the system difficult to
maintain and update.

Program inspections are an old idea and there have been several studies and
experiments that have demonstrated that inspections are more effective for defect
discovery than program testing. Fagan (1986) reported that more than 60% of the
errors in a program can be detected using informal program inspections. In the
Cleanroom process (Prowell et al., 1999), it is claimed that more than 90% of defects
can be discovered in program inspections.
However, inspections cannot replace software testing. Inspections are not good
for discovering defects that arise because of unexpected interactions between dif-
ferent parts of a program, timing problems, or problems with system perfor-
mance. Furthermore, especially in small companies or development groups, it can
be difficult and expensive to put together a separate inspection team as all poten-
tial members of the team may also be software developers. I discuss reviews and
inspections in more detail in Chapter 24 (Quality Management). Automated static
analysis, where the source text of a program is automatically analyzed to discover
anomalies, is explained in Chapter 15. In this chapter, I focus on testing and
testing processes.
Figure 8.3 is an abstract model of the ‘traditional’ testing process, as used in plan-
driven development. Test cases are specifications of the inputs to the test and the
expected output from the system (the test results), plus a statement of what is being
tested. Test data are the inputs that have been devised to test a system. Test data can
sometimes be generated automatically, but automatic test case generation is impossi-
ble, as people who understand what the system is supposed to do must be involved to
specify the expected test results. However, test execution can be automated. The
expected results are automatically compared with the predicted results so there is no
need for a person to look for errors and anomalies in the test run.