Test Case

Origin & evolution

Glenford Myers fixed the philosophy in *The Art of Software Testing* (1979). His provocation was that testing is the process of executing a program with the intent of finding errors, which makes a successful test one that fails. From that follows his rule for a good test case: it must include the expected output, defined before the program runs, so the tester is forced to judge the result against a standard rather than rationalise whatever the program happens to produce.

The structure was later codified. IEEE 829, the Standard for Software Test Documentation, defines a test case by its parts: a set of input values, execution preconditions, expected results, and postconditions, written for a stated objective🏁ObjectiveStrategyA strategic goal (OKR)View reference → such as exercising a particular path or verifying a specific requirement. That last clause matters. It ties each test case back to a requirement, which is how a team answers "have we tested everything we promised?"

Practice then split along two lines. The agile movement pushed expected behaviour earlier, into executable acceptance tests and behaviour-driven specifications, so the check and the requirement are written together. Test automation moved the bulk of routine cases into code that runs on every commit, leaving humans for the exploratory work machines handle poorly. The unit stayed the same throughout: one case, one expected result, one verdict.

How it works in practice

A team builds a password reset flow. One acceptance criterion✅Acceptance CriterionProduct SpecificationA condition that must be met for a story to be doneView reference → reads: "a reset link expires 30 minutes after it is issued." That single criterion spawns several test cases. One has the precondition of a link issued 29 minutes ago, the step of clicking it, and the expected result that the reset form loads. Another sets the link at 31 minutes old and expects a clear "link expired" message with an option to request a new one. A third feeds a link that was already used once and expects rejection. Each case is independently runnable and gives a clean pass or fail. The first is automated as part of the regression suite; the awkward edge of a clock that crosses the boundary mid-request gets a manual case, because the timing is fiddly to reproduce in code. Together they pin the criterion down from every angle a real user might hit.

Test case vs. its neighbours

• Acceptance criterion states the condition a requirement must satisfy, in the user's terms. A test case is one concrete way of checking it, in the tester's terms. One criterion usually needs🫀NeedUserA user need, pain, desire, or constraintView reference → several test cases to cover its boundaries, so the relationship is one-to-many by design.
• Test suite📂Test SuiteQuality AssuranceA suite of related testsView reference → is a named collection of test cases run together, grouped by feature⭐FeatureProduct SpecificationA product capability or featureView reference →, release🚢ReleaseProduct SpecificationA shipped version of the productView reference →, or risk🎲RiskComplianceA risk to the product or businessView reference →. The suite is the container; the test case is the contained unit. A suite passes only when every case in it passes.
• Test result🎰Test ResultQuality AssuranceA test execution resultView reference → is the outcome🏆OutcomeStrategyA desired business or user outcomeView reference → of running a case once: pass, fail, or blocked, with the observed output. The case is the reusable specification; the result is the perishable record of one execution, which is what builds a history over time.

In the graph

In the Unified Product Graph, test_case🌵Test CaseQuality AssuranceAn individual test case lives in the testing region as the atom of verification. It rolls up through test_suite_contains_test_caseTest SuitecontainsTest Casehierarchy and emits an outcome through test_case_produces_test_resultTest CaseproducesTest Resultcausal, which keeps the durable check separate from its run-by-run history. Its traceability edges are what make the structure earn its place: test_case_validates_acceptance_criterionTest CasevalidatesAcceptance Criterioncross-domain ties the check to the promise it enforces, and test_case_covers_story_statement reaches further up to the story it came from. Walk those edges backward and you can answer the question every release manager dreads, "which requirements have no tests behind them," by querying for criteria with no incoming validation.