Applicability and Limitations

Transaction testing is generally the cornerstone of system and acceptance testing. It should be used whenever system transactions are well defined. If system transactions are not well defined, you might consider polishing up your resume or C.V.

While creating at least one test case for the main success scenario and at least one for each extension provides some level of test coverage, it is clear that, no matter how much we try, most input combinations will remain untested. Do not be overconfident about the quality of the system at this point.

Summary

A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. An "actor" is a user , playing a role with respect to the system, seeking to use the system to accomplish something worthwhile within a particular context. A scenario is a sequence of steps that describe the interactions between the actor and the system.
A major component of transaction testing is test data. Boris Beizer suggests that 30 percent to 40 percent of the effort in transaction testing is generating, capturing, or extracting test data. Don't forget to include resources (time and people) for this work in your project's budget.
While creating at least one test case for the main success scenario and at least one for each extension provides some level of test coverage, it is clear that, no matter how much we try, most input combinations will remain untested. Do not be overconfident about the quality of the system at this point.

Practice

Given the "Register For A Course" use case for the Stateless University Registration System described previously, create a set of test cases so that the main success scenario and each of the extensions are tested at least once. Choose "interesting" test data using the equivalence class and boundary value techniques.

References

Beizer, Boris ( 1990 ). Software Testing Techniques (Second Edition). Van Nostrand Reinhold.

Beizer, Boris ( 1995 ). Black-Box Testing: Techniques for Functional Testing of Software and Systems. John Wiley & Sons.

Cockburn, Alistair ( 2000 ). Writing Effective Use Cases . Addison-Wesley.

Fowler, Martin and Kendall Scott ( 1999 ). UML Distilled: A Brief Guide to the Standard Object Modeling Language (2 ^nd Edition) . Addison-Wesley.

Jacobsen, Ivar, et al. ( 1992 ). Object-Oriented Systems Engineering: A Use Case Driven Approach . Addison-Wesley.

Section II: White Box Testing Techniques

Chapter List

Chapter 10: Control Flow Testing
Chapter 11: Data Flow Testing

Part Overview

Definition

White box testing is a strategy in which testing is based on the internal paths, structure, and implementation of the software under test (SUT). Unlike its complement, black box testing, white box testing generally requires detailed programming skills.

The general white box testing process is:

The SUT's implementation is analyzed .
Paths through the SUT are identified.
Inputs are chosen to cause the SUT to execute selected paths. This is called path sensitization. Expected results for those inputs are determined.
The tests are run.
Actual outputs are compared with the expected outputs.
A determination is made as to the proper functioning of the SUT.

Applicability

White box testing can be applied at all levels of system development—unit, integration, and system. Generally white box testing is equated with unit testing performed by developers. While this is correct, it is a narrow view of white box testing.

White box testing is more than code testing—it is path testing. Generally, the paths that are tested are within a module (unit testing). But we can apply the same techniques to test paths between modules within subsystems, between subsystems within systems, and even between entire systems.

click to expand

Disadvantages

White box testing has four distinct disadvantages. First, the number of execution paths may be so large than they cannot all be tested. Attempting to test all execution paths through white box testing is generally as infeasible as testing all input data combinations through black box testing.

Second, the test cases chosen may not detect data sensitivity errors. For example:

p=q/r;

may execute correctly except when r=0.

y=2*x // should read y=x
²

will pass for test cases x=0, y=0 and x=2, y=4

Third, white box testing assumes the control flow is correct (or very close to correct). Since the tests are based on the existing paths, nonexistent paths cannot be discovered through white box testing.

Fourth, the tester must have the programming skills to understand and evaluate the software under test. Unfortunately, many testers today do not have this background.