LEARN. PRACTICE. GROW.Concept and mechanism
Defect prevention starts by improving shared understanding of rules. One team describes a rejected request as terminal; another expects correction and resubmission using the same identifier. Writing tests before resolving this difference can lock in incompatible interpretations. During review, walk through examples with business, development, support, and testing. Look for states lacking a required exit, actions with undefined authorization, messages without error handling, and overlapping conditions. A review observation should identify the issue and its possible consequence so the author can respond. Counting comments without distinguishing relevance rewards volume rather than understanding. Prevention is a team responsibility, not a final inspection delegated only to the tester.
Guided application
Use distinct perspectives to enrich review: an operator looks for understandable recovery, a developer checks rule consistency, and APS considers diagnosis and operational continuity. In a state model, an arrow into a state without an exit may be correct when it represents completion; it is a defect only when it contradicts the need. A rule without a boundary example creates an opportunity for clarification, not automatic proof of incorrect implementation. Preserve decisions and update the test basis after review so discussion is not lost. When an incident reveals a false assumption, add that pattern to future reviews and check whether the action improves detection rather than merely increasing checklist length.
A terminal state is valid when it matches required behavior.
Common pitfalls
Comment treated as confirmed defect; no exit treated as always wrong; review without updating the basis.
Related topics: Analysis and evidence in the test process · Priority and residual risk · Domains, boundaries, and combinations
Review assumptions and retain actionable decisions.
Reference: Cucumber introducing example mapping · CTAL-TA v4.0 (2025)