Black Box Techniques II: Decision Table, State Transition, Use Case & Error Guessing

Equivalence partitioning and boundary value analysis work well for individual input fields. Real applications, however, also contain business rules that depend on combinations of conditions, features whose behaviour depends on history, and complete user journeys. In this lesson you will learn four more black box techniques to handle these situations, each with a worked example you can reuse in interviews.

Decision Table Testing

A decision table (also called a cause-effect table) lists combinations of conditions (inputs) and the resulting actions (outputs). Each column is a rule, which becomes at least one test case. For n conditions with Yes/No values, there are 2^n combinations: 2 conditions give 4 rules, 3 give 8 and 4 give 16.

Requirement: "A UPI payment succeeds only if the PIN is correct, the account has sufficient balance and the amount is within the daily limit. The system checks the PIN first, then the balance, then the limit, and shows the first error it finds."

Step 1: Full decision table (3 conditions = 8 rules)

Step 2: Collapsed decision table

When a condition does not affect the outcome, it is marked "–" (don't care) and rules can be merged. R5 to R8 all give "Incorrect UPI PIN", and R3 and R4 both give "Insufficient balance".

Eight combinations became four focused test cases, without losing coverage of any distinct behaviour. Collapse rules only when the requirement clearly states the order of checks; otherwise test all combinations.

State Transition Testing

Some systems behave differently depending on what happened earlier. State transition testing models the system as states, events that cause transitions between states, and the resulting outputs.

Requirement: "The user gets three attempts to enter the correct UPI PIN. After three consecutive wrong attempts, UPI PIN entry is blocked for 24 hours."

[Attempt 1] --wrong--> [Attempt 2] --wrong--> [Attempt 3] --wrong--> [Blocked]
     |                      |                      |
   correct               correct                correct
     |                      |                      |
     +----------------------+----------------------+--> [Payment Success]

Test cases derived from the model:

1. Correct PIN on the first attempt leads to payment success.
2. Wrong, then correct leads to payment success.
3. Wrong, wrong, then correct leads to payment success.
4. Three wrong attempts lead to Blocked with a clear message.
5. In the Blocked state, entering the correct PIN must not process the payment (invalid transition).
6. After a successful payment, the next payment starts again at Attempt 1 (counter reset).

Other common examples include order status (Placed, Packed, Shipped, Delivered, Returned) and train ticket status (Waitlisted, RAC, Confirmed, Cancelled). Always test invalid transitions too: for example, a Delivered order should not move back to Packed.

Use Case Testing

A use case describes how an actor (user or external system) interacts with the system to achieve a goal. Use case testing derives tests from the main flow, alternate flows and exception flows, which makes it ideal for end-to-end and UAT scenarios.

Error Guessing

Error guessing is an experience-based technique where the tester anticipates likely mistakes based on past defects, domain knowledge and intuition. It complements formal techniques rather than replacing them. A useful checklist: