Testing Strategy - Software Testing: Testing Across the Entire Software Development Life Cycle - page 67

black box testing (you just have the executable code—behavior)
performance testing (Is the program somehow fast enough?)
Let us take a high-level look at the “moves” that these testing approaches provide.
Once you understand the basic strategy of a testing plan, we will drill down into a
more detailed discussion of each testing approach.
4.2.1 StaticTesting
As we saw in Chapter 1, 85% of all software defects are introduced at the Design
phase of development. The burning question is “What is there to test during the
Design phase to reduce these defects?” The resounding answer is not “code!” The
actual programming occurs in a later phase. If code is not available to test at the
beginning of a development project, then what is? The answer is “documentation.”
Software development starts, continues, and ends with documentation. Early docu-
mentation is used to defi ne the software to be built. Later documentation covers
the software training, installation, and operation (user guides). There is plenty of
documentation to test anytime in a software development project. Many developers
view the writing of documentation as an afterthought. The truth is just the opposite.
The more time and effort spent developing good documentation, especially require-
ments, design, and specifi cations, the better chance the developer has to write good
code from that documentation. If you are now convinced that testing documentation
is just as important as testing the code, then your next question will be “how do
I test documentation ?” The short answer is by desk checking, inspections, walk-
throughs, and presentations. All of these techniques are different ways of examining
the correctness and completeness of the document being tested. Once discovered,
document defects need to be diligently tracked to correction; otherwise, the docu-
ment defect will remain in the document to cascade into many more defects in sub-
sequent development phases.
Testers are the best group to static test development documents for two reasons.
First, the testers are trained in appropriate document testing techniques seldom
learned by the developer. Second, the testers represent an objective third party who is
much more likely to identify document defects (especially what is missing) than the
document author whose sense of ownership typically clouds the testing objectivity.
We will discuss some static testing techniques in Chapter 6. You just need an
appreciation of static testing in order to do your test planning.
4.2.2 White Box Testing
White box testing is that kind of software testing you can do when you have both
the source code and the executable code in hand. This situation is fairly common
for in-house developers who are writing a new system or upgrading an existing
system custom built for their company. Another group of developers who typically
have access to the source code are developers of software for sale. If you purchase