Software QA / Basic: reasoning and test design / Lesson 5

Decision tables and state transitions

Model rules that depend on combinations and histories. Derive concrete tests for scholarship eligibility and enrollment cancellation without treating a list of screens as a complete behavioral model.

About 4 min readContent reviewed 2026-10-23

On this page

Lesson goals

Translate combined conditions into decision rules.
Test valid and invalid state transitions.
Explain model coverage and missing histories.

Make combinations visible

A scholarship is available when a learner has verified eligibility and has not already used the scholarship this year. Testing each condition independently is insufficient if the implementation combines them incorrectly. A decision table makes combinations explicit and associates each with an action. Begin with all feasible combinations, then simplify only when a condition genuinely cannot change the action. Record impossible combinations with a reason rather than deleting inconvenient cases. Ask whether missing or unknown data is a third state; a Boolean model can conceal a pending verification that the real workflow supports.

Worked case: scholarship approval

Prepare a separate learner for each rule so prior approvals do not contaminate later cases. In rule R1, verified eligibility and no previous use produce one approval and one usage record. In R2, previous use causes rejection despite verification. R3 and R4 reject unverified learners regardless of previous use. Check that rejected requests create no usage record. If all four cases pass, report coverage of these four modeled rules, not all possible scholarship behavior: annual rollover and pending verification still need their own tests.

text Four feasible decision rules

Rule | Verified | Used this year | Result
R1 | yes | no | approve once
R2 | yes | yes | reject
R3 | no | no | reject
R4 | no | yes | reject

R4 remains useful even if rare; it detects code that grants eligibility based only on history.

History changes what an action means

An enrollment can be pending, confirmed, or canceled. “Cancel” means something different in each state: pending cancellation may release a reservation, confirmed cancellation may request a refund, and repeating a canceled action must not create another refund. Define transitions using state, event, guard condition, and effect. Include invalid events such as confirming a canceled enrollment. A screen is not necessarily a state; two screens can show the same business state, while one screen can represent several states with different permitted actions.

Worked case: a repeated cancellation

Create a pending enrollment, confirm it, cancel it, and then cancel it again using the same enrollment identifier. After the first cancellation, expect canceled status and exactly one refund request under the agreed policy. After the second, expect the same status and unchanged refund count. This sequence checks more than visiting all three states: it investigates an event from a terminal state. Preserve timestamps and identifiers as evidence. Do not reset the object between sequence steps, because doing so would remove the history this case is designed to test.

text Transition examples with effects

Current | Event | Expected next state / effect
pending | confirm | confirmed / reserve seat permanently
confirmed | cancel | canceled / one refund request
canceled | cancel | canceled / no additional refund
canceled | confirm | rejected / remains canceled

The final row checks an invalid transition; state coverage alone would not require it.

Name the coverage criterion

State coverage asks whether every modeled state was reached; transition coverage asks whether every modeled transition was exercised. Neither guarantees every path, guard, concurrent event, or long history was checked. A model can be wrong or incomplete, so review it against stakeholder examples and production incidents. Prioritize combinations with plausible harm and use exploratory testing to challenge simplifications. When the workflow changes, update the diagram or table and linked tests together; an obsolete model can make a strong-looking coverage percentage positively misleading.

Common errors and fixes

Checking conditions without their combinations

Why it happens: The interaction between AND and OR is ignored.
How to fix it: List feasible rules and assert each action.
Prevent it next time: Review a decision table for combined policies.

Equating screen visits with state coverage

Why it happens: Presentation is mistaken for business state.
How to fix it: Observe persisted status and permitted events.
Prevent it next time: Name states using domain concepts.

Only valid transitions are tested

Why it happens: The model omits forbidden or repeated events.
How to fix it: Add invalid transitions and verify unchanged state.
Prevent it next time: Review terminal states and retries explicitly.

Check your understanding

1. A coupon requires a paid account OR a partner code. Give all Boolean rules.

Show worked solution

Paid/partner combinations yes/yes, yes/no, and no/yes accept; no/no rejects. Use fresh accounts and assert the discount and one redemption record for accepted cases, none for rejection. A rule requiring both would be exposed by yes/no and no/yes.

2. All states were visited, but a bug allows canceled orders to ship. What is missing?