Test Case

A test case is the atomic unit of proof in software: one documented scenario, one set of inputs, one expected result. The discipline of writing them is what separates 'we checked it' from 'we verified it' — and traceability from test case back to requirement is what lets an auditor, or a court, reconstruct whether the system was ever actually proven.

What It Is

A test case is a documented scenario specifying preconditions, steps to execute, test data, and the expected result — precise enough that two different testers would reach the same verdict. Executing it produces a result: pass, fail, or blocked, with actual behaviour recorded on failure. Test cases derive from requirements (each requirement should have at least one), and collectively they form the coverage map of what has been verified. Related terms: test scripts (the executable or step-by-step form), test suites (grouped cases), and test runs (a dated execution of a suite against a build).

Why It Matters to You

The count and quality of test cases is a proxy for the depth of verification, but the executive question is traceability: for this requirement the business cares about, which test case proves it, and when did that test last pass? Requirements with no test case are unverified commitments. In disputes, executed test cases with recorded results are the evidence — which is why serious vendors version and archive them. And when your own staff perform UAT, having real test cases (rather than improvisation) is what makes the acceptance defensible if the vendor later disputes the defects you found.

When You'll Meet It

Whenever testing is planned or reported. You will review test-case counts and coverage summaries in status reports, and your UAT team will execute against test cases drawn from your BRD/SRS.