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

many reruns after many builds. Regression testing is also done from version to ver-
sion. The intent is to rerun the prior version suite of test cases on the next version
build to verify that the new version has not interfered with any prior functionality.
The next version will usually have additional functionality, one of the primary rea-
sons for a new release. Once the new version has been tested and verifi ed ready to
ship or place in production, the new functionality test activities and scripts need to
be added to the prior version regression suite.
Notice that if any of the functionality of the prior version is either changed or
removed, the prior version suite of test cases will predictably fail for those changes
or removals. The response to these test failures is not the usual attempt to try to fi x
the code; rather, the response is to retire the obsolete test activities and scripts from
the next version regression suite. Therefore, the regression suite will not be cast in
concrete per the fi rst version. Rather, it will evolve with functional additions and
changes introduced in each subsequent release.
7.5 DETAILED WHITE BOX TESTING TECHNIQUES
The objective of white box testing is to verify the correctness of the software's
statements, code paths, conditions, loops, and data fl ow. This objective is often
referred to as logic coverage. The prerequisites for white box testing include the
software requirements, use cases, the executable program, its data, and its source
code . If this topic sparks your interest, there are a number of good textbooks that can
give you more details and the results of current academic research.[29-33]
The software developer normally does white box testing as an extension of code
debugging activity early in the development cycle. Software developers usually focus
on “making the code work” according to use case activities, which gives them the
tendency to debug only the code they know works (selective logic test coverage).
Testers add value to developer debugging activity by helping the developer plan and
debug more of the code than usual (more thorough logic test coverage). The more
the logic test coverage you attain while debugging, the fewer the defects will be
discovered later by other kinds of testing.
As Capers Jones concludes, the earlier these defects can be discovered, the less
expensive they are to correct. The business motivation behind white box testing is ex-
pected economies of testing. Much of the research you will fi nd in white box testing will
relate to hypotheses, algorithms, and procedures that attempt to achieve 100% logic test
coverage under certain, very controlled circumstances. Research has not yet produced a
white box approach that guarantees 100% logic test coverage for all situations.
We will briefl y discuss six generic white box testing techniques.
7.5.1 Statement Coverage Technique
Statement coverage techniques focus on determining what percentage of the
source code lines in a program has been executed. If there are 5,000 lines of