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

off-the-shelf software, the source code is not included because the source code
represents the software vendor's trade secret.
Having the source code in hand, developers and their testing team mates have
the opportunity to review and test every line of that code. Even with all the source
code available, there is usually insuffi cient time or resources to test 100% of the
source code. With all the pieces lying on the table, developers and testers still must
create test plans that methodically test as much of the source code as practical (see
the business cost/benefi t discussion in Chapter 1).
A team of developers and testers is the best group to plan and execute white box
test source code. The developer contributes knowledge of the program specifi cations,
programming standards, and logic represented in the source code lines. It is the
developer who knows what the code is supposed to do and how to prove that the
code is doing it (positive testing). The developer is also the person who has access
to the source code for testing execution. The tester contributes knowledge of white
box testing techniques that will cause the developer to look beyond just proving that
code works as specifi ed to fi nd out if the user can inadvertently “break” the code
(negative testing). The combination of positive testing and negative testing are what
make white box testing the most effective at fi nding defects.
There are several useful white box techniques for commercial software developers
and testers. White box testing is also referred to as “logic path” testing because of
the dominance of logic path analysis for this technique. We will examine these white
box techniques in a subsequent chapter. You just need a general appreciation now for
what white box testing is in order to do your test planning.
4.2.3 BlackBoxTesting
Black box testing is that kind of software testing you can do when you do not have
the source code, just the executable code in hand. This situation occurs at some point
in the development process regardless of the kind of development (custom software,
software for sale) being done. As the programming becomes more complete, it
is “packaged” as larger and larger components of code. This package is built by
compiling, linking, or binding executable code modules to demonstrate the collective
code's execution behavior with inputs and outputs.
Another way to get executable code for black box testing is to buy an off-the-shelf
software product. You do test the software products you buy, don't you?
A group of testers, end users (business experts), and developers is the best team
to do black box testing. The tester contributes substantial test planning and execution
expertise in positive and negative black box testing. The end user contributes
substantial knowledge of the proper business behavior to be expected of the
software. The developer contributes substantial knowledge of the business behavior
as implemented in the software (maybe different from what the user expects). The
tester drives the black box testing with the end user and developer validating ex-
pected versus actual test results. The fi rst question the tester must ask is “Do I know
the correct expected results ?” When a black box test fails (actual results do not
match expected results), the second question the tester must ask is “Did I run the test