Why Every Software Tester Should Practice Explaining Their Model Aloud

areas = [
    {"name": "Payment and refunds", "likelihood": 2, "impact": 3},
    {"name": "Search filters", "likelihood": 3, "impact": 2},
    {"name": "Profile page", "likelihood": 1, "impact": 2},
    {"name": "Footer links", "likelihood": 1, "impact": 1},
]


def depth(score):
    if score >= 6:
        return "deep: functional, negative, exploratory"
    if score >= 3:
        return "medium: main flows and key negatives"
    return "light: smoke check"


for area in areas:
    area["score"] = area["likelihood"] * area["impact"]

for area in sorted(areas, key=lambda a: a["score"], reverse=True):
    print(f"{area['score']:>2}  {area['name']:<20} {depth(area['score'])}")

"I scored each area on likelihood and impact from one
to three. Likelihood went up for anything that changed
recently or depends on an outside system. Impact went
up for money, data and blocking the main user journey.

Payment and search both scored six, but for different
reasons: payment because failure is expensive, search
because it was rewritten. So payment got deeper negative
tests, and search got broader regression.

The profile page scored two, so I only smoke-tested it
and said so in my summary."

TRANSITIONS = {
    ("Placed", "pay"): "Paid",
    ("Placed", "cancel"): "Cancelled",
    ("Paid", "ship"): "Shipped",
    ("Paid", "cancel"): "Cancelled",
    ("Shipped", "deliver"): "Delivered",
}
STATES = ["Placed", "Paid", "Shipped", "Delivered", "Cancelled"]
EVENTS = ["pay", "cancel", "ship", "deliver"]

valid, invalid = [], []
for state in STATES:
    for event in EVENTS:
        target = TRANSITIONS.get((state, event))
        if target:
            valid.append(f"{state} --{event}--> {target}")
        else:
            invalid.append(f"{state} --{event}--> REJECT")

print("Valid transitions to test:", len(valid))
print("\n".join(valid))
print("\nInvalid transitions to test:", len(invalid))
print("\n".join(invalid))

"The order has five states and four events.
I wrote the allowed moves as a table, then generated
every state and event pair.

Five valid transitions become positive test cases.
The other fifteen pairs are invalid, for example
paying twice, or cancelling after delivery.

I did not run all fifteen with equal effort. I picked
the risky ones first: pay on Paid, which could double
charge, and cancel on Shipped or Delivered, which could
trigger a wrong refund."

Add a third condition: coupon FREESHIP applied (Y/N)
2 x 2 x 2 = 8 combinations

      | C1 Member | C2 Above threshold | C3 Coupon | Result
------|-----------|--------------------|-----------|---------
R1    |    Y      |        Y           |    Y      | Free
R2    |    Y      |        Y           |    N      | Free
R3    |    Y      |        N           |    Y      | Free
R4    |    Y      |        N           |    N      | Free
R5    |    N      |        Y           |    Y      | Free
R6    |    N      |        Y           |    N      | Free
R7    |    N      |        N           |    Y      | Free?
R8    |    N      |        N           |    N      | Charge

R7 is not defined in the requirement.
Does the coupon work for non-members below the threshold?

"Shipping depends on three yes-or-no conditions, so
there are eight combinations. I wrote all eight as rules.

Six of them clearly give free shipping and one clearly
charges. But the requirement never said what happens
when a non-member below the threshold uses the coupon.

I raised that with the product owner before testing.
The answer was that the coupon should work, so R7
became a test case, and it actually failed on the
first build."

RISK MODEL FOR: ____________________

Area         | Likelihood 1-3 | Why | Impact 1-3 | Why | Score
-------------|----------------|-----|------------|-----|------
____________ |                |     |            |     |
____________ |                |     |            |     |
____________ |                |     |            |     |
____________ |                |     |            |     |

Likelihood rises with: recent change, complexity,
  external integrations, past defects.
Impact rises with: money, data loss, security,
  blocking the main user journey.

STATE MODEL FOR: ____________________

States: ______, ______, ______, ______, ______
Events: ______, ______, ______, ______

Total state-event pairs = states x events = ____

Valid transitions (positive cases):
  ______ --______--> ______
  ______ --______--> ______

Riskiest invalid transitions (negative cases):
  ______ --______--> must be rejected because ______
  ______ --______--> must be rejected because ______

TWO-MINUTE MODEL EXPLANATION

1. The feature and why it needed a model    (15s)
2. Which model and why that one             (15s)
   risk matrix / state diagram / decision table
3. Walk the model briefly                   (30s)
4. How many cases it produced, valid vs invalid (20s)
5. One gap or bug the model revealed         (25s)
6. What the model did not cover              (15s)

Record it. If step 5 is empty, build the model
again more carefully. Models should find something.