Test Case Template for a Small Web App
By SayCraft Team · 2026-08-26 · 4 min read
A useful test case template identifies the exact build and environment, user role, starting state, safe test data, prerequisites, numbered actions, observable expected result, actual result, evidence, defect ownership, and retest status. Keep one primary behavior per case and include negative and recovery paths as separate cases.
Community signal: Fast-changing previews make vague pass or fail notes hard to reproduce. A build-specific executable row gives another reviewer the same state, actions, expected result, evidence, and retest history.
What a test case must make repeatable
A useful test case template identifies the exact build and environment, user role, starting state, safe test data, prerequisites, numbered actions, observable expected result, actual result, evidence, defect ownership, and retest status. Keep one primary behavior per case and include negative and recovery paths as separate cases.
Copyable test-case row
Copy the blank rows below into a document, issue, or spreadsheet and replace every bracketed field. Keep one primary behavior per case so another reviewer can execute it without oral setup or private production data.
Create the starting state through a repeatable fixture or documented setup. Execute exactly the numbered actions, preserve actual evidence before discussing causes, and record blocked rather than guessed when a prerequisite is missing. When a fix arrives, rerun the original case and any directly dependent case on the new build while retaining the earlier failure record.
- TC-[ID] | Requirement: [ID] | Priority: [P0-P3] | Owner: [name] | Review owner: [name]
- Build: [immutable version] | Environment: [name] | Browser or device: [value] | Role: [role] | Flags and network: [state]
- Preconditions: [repeatable setup] | Sanitized data: [fixture] | Starting state: [observable state]
- Step 1 | Action: [single action] | Expected result: [observable outcome]
- Step 2 | Action: [single action] | Expected result: [observable outcome]
- Actual result: [observation] | Evidence: [link or file] | Status: [pass, fail, blocked] | Defect: [ID]
- Retest build: [version] | Retest result: [observation] | Regression cases: [IDs] | Closure owner and date: [value]
Expired-invitation example
For an expired invitation, the case fixes the build, browser, signed-in account, invitation state, and link age. The expected result is a safe expired-link message and recovery route. The tester records the actual page, evidence, defect ID, and the build used for retest.
- Freeze the build and environment
- Describe a reproducible starting state
- Write actions without expected outcomes inside them
- Record evidence and retest separately
Freeze build, role, state, and data
A repeatable case begins before step one. Record the application build, environment, browser or device, account role, permissions, feature flags, seed data, network condition, and any object identifiers needed to reproduce the starting state. Use sanitized test data. If setup depends on an undocumented action or a one-off database change, the case is not yet portable enough for another reviewer.
Distinguish a scenario, case, and suite. A scenario names a journey or risk; a case makes one path executable with state, actions, and expected evidence; a suite groups cases for a release or regression purpose. Keep that hierarchy in IDs rather than publishing several near-duplicate templates. A case passes only on the tested build and conditions, and its result does not silently transfer to another role, device, feature flag, or data state.
- Atlassian: acceptance criteria examples
- Atlassian: user acceptance testing template
Write actions and observable outcomes
Write one sequence of user actions and one observable result. Actions should not contain the expected answer, and expected results should cover visible state, persisted state after refresh, messages, permissions, and recovery where relevant. Create separate cases for invalid input, interrupted requests, duplicate actions, revoked access, and retries instead of packing many branches into one ambiguous pass or fail result.
Record failure, defect, and retest evidence
Preserve execution evidence by build. Record actual result, timestamp, screenshot or safe log, status, defect link, owner, and reason when blocked. After a fix, run the same case on the named successor build and record retest evidence without overwriting the original failure. Passing a small set of cases does not establish complete coverage, production security, accessibility, or compliance.
Limits of a test-case set
A preview is not evidence of production security, compliance, or launch readiness.
- A second reviewer can execute the case
- Expected and actual results are distinct
- Test data contains no secrets or personal data
- Pass status cites observable evidence
Sources and discussion
- Atlassian: acceptance criteria examples (publisher)
- Atlassian: user acceptance testing template (publisher)
Community posts describe individual experiences and questions; they are not treated as universal proof.
Related resources
Build the next step with SayCraft
Write the highest-risk cases before polishing the happy path, then preserve the observed result for each build. SayCraft can support preview iteration; responsible testers and engineers own coverage, diagnosis, and release acceptance.