Master Black-Box Test Cases: Equivalence, Boundary, and Scenario Techniques

Definition and Role of Test Cases

IEEE Standard 610 defines a test case as a set of inputs, execution conditions, and expected results designed for a specific purpose. A test case is the smallest executable entity that verifies a software program behaves correctly in a particular scenario.

Because it is impossible to test every possible scenario, engineers must select representative cases that satisfy the characteristics shown in Figure 1‑2.

Black‑Box Test Case Design Methods

1. Equivalence Class Partitioning

Divides the input domain into classes and selects representative values from each class. If a representative fails, the whole class is considered faulty.

Example with triangle sides a, b, c: valid inputs must satisfy a>0, b>0, c>0 and the triangle inequalities a+b>c, b+c>a, a+c>b. Additional constraints for special triangles are listed.

If the triangle is isosceles, a = b or b = c or a = c.

If the triangle is equilateral, a = b = c.

The equivalence‑class table (Figure 1‑3) and the corresponding test‑case table (Figure 1‑4) illustrate how inputs a, b, c map to expected outcomes.

2. Boundary Value Analysis

Focuses on values at the edges of input domains and just beyond them. It is widely used to expose defects that occur at boundary conditions.

Two main categories of boundaries are shown in Figure 1‑5:

Requirement constraints (e.g., a username must start with a letter and be exactly five characters long).

Functional compliance boundaries (e.g., a calculator must reject non‑numeric symbols).

Secondary boundaries such as variable ranges, ASCII limits, array bounds, and null values are also considered.

3. Scenario Method

Developed by Rational, this method models the system as a set of basic flows (main process) and alternate flows (exceptional branches). Test cases are derived from full coverage of both flows.

Figure 1‑6 shows basic and alternate flows; Table 1‑3 provides a simplified scenario example for an online book‑purchase process.

For the purchase scenario, the basic flow includes steps such as visiting the homepage, logging in, searching for a book, and completing payment. Alternate flows cover account issues, password problems, out‑of‑stock books, and nonexistent titles.

Alternate flow 1: Account problem.

Alternate flow 2: Password problem.

Alternate flow 3: Book out of stock.

Alternate flow 4: Book not found.

Test cases are organized in a decision matrix (Figure 1‑7) where “V” marks required valid conditions and “I” marks conditions that trigger an alternate flow.

Key take‑aways: the basic flow may have multiple paths, and alternate flows depend on the specific business logic. The scenario method is especially suitable for testing scheduled‑task workflows.