Choose appropriate test data for a test plan

12.3 Program Testing and Maintenance

Objective: Choose appropriate test data for a test plan

Effective testing requires not only a clear test plan but also carefully selected test data that

reveals faults while keeping the effort reasonable. The following notes describe the main techniques

for choosing test data and illustrate how they can be applied in a systematic test plan.

1. Why test‑data selection matters

• Reduces the number of test cases while maintaining coverage.
• Targets the most error‑prone parts of the program.
• Helps to detect both typical and atypical behaviour.
• Supports traceability between requirements, test cases and defects.

2. Common test‑data selection techniques

2.1 Equivalence Partitioning (EP)

Divide the input domain into classes (partitions) that are expected to behave similarly.

One representative value from each class is sufficient to test that class.

2.2 Boundary \cdot alue Analysis (B \cdot A)

Errors often occur at the edges of partitions. For each numeric range, test the minimum,

just‑above minimum, maximum, just‑below maximum and a typical interior value.

2.3 Decision Table Testing

When output depends on several conditions, a decision table lists all possible combinations.

Each column becomes a test case.

2.4 State‑Transition Testing

For programs that change state (e.g., UI workflows, protocol handlers), identify states,

events, and transitions. Test each transition, especially those that lead to error states.

2.5 Error Guessing

Based on experience, anticipate typical programmer mistakes (off‑by‑one, null pointer,

incorrect loop limits) and create test data that might trigger them.

3. Step‑by‑step process for selecting test data

1. Identify inputs and outputs from the specification.
2. Classify inputs using EP; note valid and invalid partitions.
3. Apply B \cdot A to each numeric partition.
4. Construct decision tables for logical combinations of conditions.
5. Map state diagrams to test transitions.
6. Add error‑guessing cases based on known pitfalls.
7. Prioritise test cases (e.g., high‑risk, high‑frequency, critical functionality).
8. Document test data in the test plan (see example table below).

4. Example: Choosing test data for a simple “Student Grade” program

The program takes a numeric mark (0–100) and returns a grade:

\$\$\text{Grade} =

\begin{cases}

\text{A} & \text{if } 80 \leq m \leq 100\\

\text{B} & \text{if } 70 \leq m < 80\\

\text{C} & \text{if } 60 \leq m < 70\\

\text{D} & \text{if } 50 \leq m < 60\\

\text{F} & \text{if } 0 \leq m < 50\\

\text{Invalid} & \text{otherwise}

\end{cases}

\$\$

4.1 Applying EP and B \cdot A

4.2 Decision Table for special cases

If the program also checks for “late submission” (boolean flag) and applies a penalty, a decision

table can be built:

5. Sample Test Plan excerpt

The following table shows how selected test data are recorded in a test plan.

6. Tips for exam questions

• Always state the partition and why the chosen value represents it.
• For numeric ranges, list at least three values: minimum, just above minimum, maximum, just below maximum, and a typical interior value.
• When a decision table is required, include all condition combinations, even those that lead to the same output.
• Explain any error‑guessing cases you add – show the likely programming mistake.
• Use clear, concise test‑case identifiers to match the test plan.