Learning Objectives
By the end of this lesson you will be able to:
- Apply the probe-observe-model cycle to reverse-engineer hidden business logic
- Write charters specifically for systems with undocumented rules
- Build a decision table from observed behavior rather than a specification
When the Spec Is Missing
You join a project. The feature was shipped two years ago. The developer who built it left. The "specification" is a Slack thread and three screenshots. The product owner says "just test it and tell me if anything looks wrong."
This is not an unusual scenario. And it is not a free pass to do nothing. It is an invitation to deploy the most advanced skill in your toolkit: reverse-engineering the rules from behavior.
The Probe-Observe-Model Cycle
Probe: Design an input based on a hypothesis. "If the rule is X, then input Y should produce output Z."
Observe: Submit the input. Record exactly what happens — output, error message, behavior change.
Model: Update your mental model based on the observation. If Z happened, your hypothesis was supported. If something else happened, revise the hypothesis.
Repeat until your model predicts all observed behavior.
Starting Without Any Knowledge
When you know nothing:
- Submit the simplest possible valid input and observe the output
- Try the simplest possible invalid input and observe the response
- Vary one parameter at a time and observe what changes
These three steps give you your first mental model, which you then refine.
Building a Decision Table From Observations
Example: you're testing a promo code system with no specification. You observe:
| Experiment | Customer | Amount | Day | Code | Result |
|---|---|---|---|---|---|
| 1 | New | €50 | Mon | SAVE20 | Applied ✓ |
| 2 | New | €200 | Mon | SAVE20 | Applied ✓ |
| 3 | New | €50 | Sat | SAVE20 | Applied ✓ |
| 4 | Returning | €200 | Sat | SAVE20 | Applied ✓ |
| 5 | Returning | €50 | Sat | SAVE20 | Not Applied ✗ |
| 6 | Returning | €200 | Mon | SAVE20 | Not Applied ✗ |
Hypothesis emerging: "Discount applies if (customer=New) OR (returning AND amount>€100 AND day=Saturday)."
Verify with a targeted probe:
- Experiment 7: Returning, €100 exactly, Saturday → Applied or not? (boundary check)
- Experiment 8: Returning, €201, Friday → Not applied (should confirm day matters)
This is decision table testing performed backward: you build the table by observing behavior rather than reading requirements.
Charter for Hidden Logic
Mission: Reverse-engineer the eligibility rules for the promo code system. Area: Promo code application on the cart page. Risk: Undocumented conditions, boundary values off by one, conditions that interact in non-obvious ways.
The session output is your decision table — which becomes the reference spec against which bugs can now be measured.
Pro Tip: When you find an inconsistency (behavior doesn't match your model), that's the bug. "Based on my observations, returning customers with >€100 on weekends should get the discount. This returning customer with €200 on Saturday did not. This is a defect or an undocumented exception." You can write a bug report without a written specification.
The Tester as Specification Writer
When no spec exists, reverse-engineered behavior becomes the spec. Document it. Review it with the product owner. Get it signed off. You've just transformed an untested black box into a tested, specified, documented feature — using only exploratory charters and systematic observation.
Summary
Hidden business logic is not an obstacle — it's an invitation to use your most advanced skills. The probe-observe-model cycle, combined with charter discipline and decision table thinking, lets you build a complete model of a feature from scratch. This lesson concludes the course. You now have a full toolkit for every type of combinatorial, logical, and behavioral testing challenge you will encounter in the Testing Wilderness.