Test case template
A modern IEEE 829-inspired test case template. Eight fields, one scenario per case, designed to survive code review and produce binary pass-or-fail results.
What it is for
A test case is one experiment with a clear hypothesis, a controlled setup, and a binary outcome. It is read, run, and maintained for years; a sloppy test case costs a team hours every release.
Who uses it
Every QA engineer. Also developers writing unit and integration tests, who borrow the same structure.
The template
**ID**: {{TC-COMPONENT-NNN}}
**Title**: {{One sentence from the user point of view. No "and".}}
**Component**: @{{component}} @{{platform}}
**Priority**: P0 / P1 / P2 / P3
**Automated**: yes / no (path to file if yes)
## Preconditions
- {{Required state before the test starts}}
- {{User exists with specific role / KYC status}}
- {{Test data seeded}}
## Test data
- {{Field: specific value, e.g. mobile: +91 98765 43210}}
- {{Field: specific value}}
## Steps
1. {{One action per step}}
2. {{One action per step}}
3. {{One action per step}}
## Expected result
- {{Binary pass/fail outcome}}
- {{Visible UI assertion if applicable}}
- {{Backend / DB assertion if applicable}}
## Negative variants (separate test cases)
- {{TC-XYZ: variation 1, expected result}}
- {{TC-XYZ: variation 2, expected result}}
Placeholders like {{...}} mark fields you replace. Everything else is structure you keep.
Worked example
**ID**: TC-LOGIN-007 **Title**: Successful login with valid mobile + correct OTP lands on /me **Component**: @auth @web @mobile **Priority**: P0 **Automated**: yes (pytest, tests/auth/test_login.py::test_successful_login) ## Preconditions - A user account exists for +91 98765 43210 - The account is in 'active' state with KYC status 'verified' - The OTP sandbox is reachable (healthcheck < 1s) ## Test data - Mobile: +91 98765 43210 - OTP: 123456 (sandbox returns this for any number) ## Steps 1. Open https://juice.upcode.in/login 2. Enter mobile number +91 98765 43210 3. Tap 'Send OTP' 4. Wait up to 5 seconds for the OTP input to appear 5. Enter OTP 123456 6. Tap 'Verify & continue' ## Expected result - The browser navigates to /me within 3 seconds - The greeting "Welcome back" is visible above the fold - A row exists in activity_log with kind='login' for the user - The 'login' event fires in the dataLayer (verified in DOM dataLayer property) ## Negative variants (separate test cases) - TC-LOGIN-008: empty OTP. Expected: 'Enter all 6 digits' toast appears; form does not submit - TC-LOGIN-009: wrong OTP. Expected: 'Incorrect code' toast; OTP cleared; cursor returns to first digit - TC-LOGIN-010: same OTP submitted twice. Expected: second submission ignored (idempotent) - TC-LOGIN-011: OTP entered after 10 minutes. Expected: 'OTP expired' error, link to resend
Common mistakes
- ›One scenario per test case. If your title has "and", split it.
- ›Concrete data, not placeholders. "Valid email" is a bug. "[email protected]" is a test.
- ›Independent of every other test case. If reading TC-031 is required to understand TC-032, fix TC-032.
- ›Negative variants are first-class. Roughly half a mature suite is negative cases.
- ›Steps are runnable by a new joiner on day one. If they need context, your title is wrong.
Other QA templates
Want to learn how to use these on real projects? The Pro Software Testing program covers test plans, test cases, and bug reporting in Phases 3-6 with peer review on every submission.