Functional Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 110

series of arithmetic, replacement, input/output, branching, and looping statements to
a return/stop/end/exit statement. If there are 943 different paths through a program
and you can determine manually or with a tool that you have executed 766 of them,
then you have achieved an 81.2% path coverage (exceptionally high for complex
programs). The underlying hypothesis is that the higher the path test coverage, the
fewer will be the defects found later. The practical conclusion is that unexecuted
paths are just a time bomb waiting to explode at the most inopportune moment in
production, even though all of the statements and branch points in the path have been
individually tested.

7.5.5 Loop Coverage Technique

Loop coverage techniques focus on determining what percentage of the source code
loops in a program has been cycled completely. There are several loop constructs
in programming languages like DO, FOR, WHILE, and UNTIL. Some loops are
a clever construct of IF statements and subsequent returns to these IF statements.
Regardless of the loop construct, the objective of loop testing is to force the program
through the loop zero times, one time, n /2 times (where n is the terminal loop value),
n times, and n 1 times. The one-time loop, the n /2-time loop, and n -time loop

validate expected loop response at the beginning, middle, and end of the longest loop.
The zero-time and n

1-time loop test for unexpected and inappropriate looping
conditions. We will see this end-point/mid-point testing tactic again in black box
boundary value testing. If there are 732 loops in a program and you can determine
manually or with a tool that you have executed 312, then you have achieved a 42.6%
loop coverage (about average for complex programs). The underlying hypothesis is
that the higher the loop test coverage, the fewer will be the defects found later. The
practical conclusion is that unexecuted loops and loops execute only within expected
loop limits are just a time bomb waiting to explode at the most inopportune moment
in production.

7.5.6 Intuition and Experience

This section is devoted to those software aspects that experienced testers have
found to be troublesome areas of coding that the more formal debugging and testing
techniques tend to miss. Here is a summary of those troublesome aspects.

7.5.6.1 Dates

Dates present three unique data challenges to the developer: valid formats, sort
sequence, and calculations. The original mm/dd/yyyy format of dates remains
problematic because for each mm (month) there is a specifi c range of values for
dd (day) depending on yyyy (years like leap years). The validation of mm versus
dd versus yyyy remains complex and grows more because we crossed the century
boundary with computer systems (the infamous Y2K problem). The global nature