Test Case Template With Complete Software Testing Examples
By SayCraft Team · 2026-08-26 · 11 min read
A test case describes repeatable setup, action, and an observable expected result. Use it when another tester must be able to recreate the same condition and compare the result with a stated requirement or risk. Record the preconditions, safe data, numbered steps, expected behavior, and intended environment before execution. Do not record a pass before anyone runs it: keep Actual result, Status, Evidence, and Retest blank until the specified build and environment have been tested. The template and five connected examples below cover positive, negative, boundary, permission, and recovery behavior.
Copyable test case template
| Field | What to record |
|---|---|
| ID and requirement/risk | A stable identifier and the behavior or risk covered |
| Preconditions and data | Required account, state, permissions, fixtures, and safe test data |
| Steps | Numbered actions another tester can repeat |
| Expected result | Visible system behavior after the action |
| Actual result | What happened during this execution |
| Environment/build | Device, browser/OS, release or commit tested |
| Status and evidence | Pass/fail/blocked plus screenshot, log, or record reference |
| Owner/retest | Defect owner, fix build, retest result |
Worked examples: draft approval
| Case | Action | Expected result |
|---|---|---|
| TC-01 positive | Invited client approves the current draft. | Status changes once to Approved and records client and draft version. |
| TC-02 negative | Unrelated signed-in user opens the approval URL. | No draft data is shown; a permission message and safe exit are available. |
| TC-03 boundary | Upload a file exactly at the documented size limit, then one byte over. | The limit file is accepted; the larger file is rejected before upload with a clear size message. |
| TC-04 permission | A read-only reviewer attempts to request changes. | The action is unavailable and the server rejects a forged request. |
| TC-05 recovery | Disconnect during upload, reconnect, and choose Retry. | The UI leaves Failed state, restarts safely, and creates one draft rather than duplicates. |
Complete execution-ready example
ID: TC-05 Requirement/risk: interrupted upload must recover without a duplicate draft Preconditions: invited designer; Project A; no existing draft for the fixture Test data: sanitized 4 MB sample.pdf Steps: start upload; disconnect network during progress; wait for Failed; reconnect; choose Retry Expected result: retry reaches Ready and Project A contains exactly one new draft Actual result: Environment/build: Status: Evidence: Owner/retest:
Scenario, test case, and checklist
- Scenario: a broad condition worth testing, such as “client approves a draft.”
- Test case: repeatable inputs, steps, and expected results for one behavior.
- Checklist: a compact reminder of coverage where detailed steps would add little value.
Trace important cases to acceptance criteria. Use the UAT checklist for business acceptance and the mobile checklist for platform-specific coverage.
Sources used for this guide
Turn the document into something testable
Use the highest-risk case as the acceptance boundary for a small live build. The preview is ready for review when the observed result matches the specified result—not merely when the page renders.
Frequently asked questions
What should a test case include?
Include the requirement or risk, preconditions, data, steps, expected result, environment and build. Fill in actual result, status, evidence, and retest information only when the test is executed.
What is the difference between a test case and checklist?
A test case records repeatable setup, action, and expected behavior. A checklist is lighter coverage used when detailed repeatability is unnecessary.