A review of “Black-Box Testing” by Boris Beizer

In “Black-Box Testing” Boris Beizer describes a number of useful techniques that can be used for black-box testing. He defines black-box testing as “the testing you do when you put yourself in the software user’s place to verify that it behaves the way it’s supposed to”.[1] Each testing technique is described in a chapter which has the same structure: synopsis, vocabulary, the relations and the model, the technique, application considerations, summary and self-evaluation quiz. IRS forms are used to create examples of each technique.

The first chapter gives an introduction to graphs and relations, subsequent chapters are on testing techniques.

Control-flow graphs are “introduced as the basic model for test design”[2]. Beizer takes us through how to model the functionality being tested as a control-flow graph, select the test paths, and sensitise a graph with data.

Bugs often accompany loops [3] and loops can be tested if the loops are depicted in a graph. The critical test values that are used to control the loop can be described in a graph. Deterministic loops, which for example may handle a paycheck for one to 20,00 employees[4] can be tested as can non-deterministic loops, which for example may search for a file of unknown length[5].

Data flow can be tested by data flow graphs. There are similarities between control flow graphs and data flow graphs because ordinary processing is similar.[6]

“The transaction flow graphs can used in system testing of on-line applications and batch-processing software” [7] The technique pays attention to queues and loops. 

Domain testing “replaces the common heuristic method of testing extreme values and limit values of inputs” [8]. This chapter provides a way of testing where a domain boundary is missing an upper or lower value. It can be useful to read this chapter in conjunction with the chapter in The Art of Software Testing that describes boundary value analysis because they both discuss how to test the same types of values.

Syntax testing is used for “testing command-driven software”[9].

The “finite-state machine model is an excellent model for testing menu-driven applications”[10]. A finite-state machine consists of state, transitions, inputs and outputs and is depicted by state graphs.[11]

Over time tests become less effective at finding bugs. This is described as the “Pesticide paradox”, and testers have to learn to create new tests. [12] 

Black-box testing is a very useful book. I have a well-thumbed copy of the book, which I use as a reference when I need to use one of the techniques Beizer describes.

References

[1] Black-Box Testing by Boris Beizer (1995, pxi)

[2] Black-Box Testing by Boris Beizer (1995, p38)

[3] Black-Box Testing by Boris Beizer (1995, p70)

[4] Black-Box Testing by Boris Beizer (1995, p38)

[5] Black-Box Testing by Boris Beizer (1995, p70)

[6] Black-Box Testing by Boris Beizer (1995, p91)

[7] Black-Box Testing by Boris Beizer (1995, p122)

[8] Black-Box Testing by Boris Beizer (1995, p146)

[9] Black-Box Testing by Boris Beizer (1995, p178) 

[10] Black-Box Testing by Boris Beizer (1995, p204) 

[11] Black-Box Testing by Boris Beizer (1995, p205) 

[12] Black-Box Testing by Boris Beizer (1995, p9)