Template · Test Case
Three test case templates, one workbook.Step-by-step, screen-by-screen, and IEEE 829 formal.
Every test case style you will need for most software engagements, in one workbook. Pick the variant that matches how your team thinks, they are equivalent in rigor, different in presentation.
- Variants
- 3
- Standard
- IEEE 829
- Use when
- Manual or automated
A test case is a written question to the system: "does this behave correctly?". The template is the grammar of the question.
Key takeaways
Four things to remember.
01
Template 1, step-by-step
For procedural, command-driven, or API-level testing. Numbered major / minor steps with a result column. Works well for automated and manual test cases alike.
02
Template 2, screen-by-screen
For GUI-heavy applications. Rows map to screens and fields; expected result is captured once at the end. Easier to author; reads faster during execution.
03
Template 3, IEEE 829 formal
For regulated or safety-critical environments. Full input / output specifications with states, timing, and inter-case dependencies. Takes longer to write; reads like a specification.
04
All three share the same core metadata
Test ID, suite, priority, hardware, software, duration, effort, setup, teardown. Pick a variant for body; the header stays the same.
Why this exists
What this template is for.
The three variants exist because one size does not fit all. A DevOps team running API regression runs Template 1. A consumer product team running manual GUI regression runs Template 2. A medical-device team running audit-visible test protocols runs Template 3.
The columns below are the union of fields across all three. Each variant populates a subset that matches the testing style.
The columns
What each field means.
Mnemonic identifier. Short enough to reference in conversation; long enough to recognize at a glance.
Five-digit hierarchical ID: XX.YYY where XX is the suite number and YYY is the test number within that suite.
The name(s) of the test suite(s) that use this case. A case may belong to multiple suites.
Derived from the quality risk coverage analysis. Drives selection order during compressed cycles.
One row per required hardware item. Match exactly to the Test Environment sheet entries.
One row per required software item, including versions.
Elapsed clock time to run the test. Distinct from effort, a 2-hour soak test has 2h duration but ~5 min effort.
Person-hours required to execute the test.
Steps to bring the system under test into the required initial state. Kept separate from the test body so the initial state can be saved and reused.
Steps to return the SUT to pretest state. Often mirrors setup in reverse.
Template 1: numbered major / minor steps with result column. Template 2: screen × field × input table. Template 3: IEEE 829 input / output spec with states, timing, dependencies.
Status, system config ID, tester, date completed, actual effort, actual duration, bug IDs linked.
Live preview
What it looks like populated.
Header fields of Template 1, the step-by-step variant.
| Field | Description |
|---|---|
| Test Case Name | Mnemonic identifier |
| Test ID | Five-digit ID, XX.YYY: XX suite number, YYY test number. |
| Test Suite(s) | The name of the test suite(s) that use this test case. |
| Priority | From quality risk coverage analysis |
| Hardware Required | List hardware in rows |
| Software Required | List software in rows |
| Duration | Elapsed clock time |
| Effort | Person-hours |
| Setup | List steps needed to set up the test |
| Teardown | List steps needed to return SUT to pretest state |
| , Body , | ID / Step / Result / Bug ID / Bug RPN |
| Execution Summary | Status, config, tester, dates, effort, duration |
How to use it
6 steps, in order.
- 1
Pick the variant that matches how your team thinks. Do not try to mix variants inside a single test suite.
- 2
Populate the common header fields (Name, ID, Suite, Priority, etc.) for every case, these drive the tracking workbook.
- 3
Write the body with one atomic check per step / row. A step that checks three things is three steps, not one.
- 4
Keep Setup and Teardown explicit, even when they seem obvious. Automated runners depend on them.
- 5
Leave the Execution Summary fields blank in the template; they are filled in when the case runs, not when it is designed.
- 6
Review authored cases with the test lead before they enter the tracking workbook. A bad case in tracking is harder to remove than a bad case in review.
Methodology
The thinking behind it.
Template 3 follows IEEE 829-2008 Test Case Specification. Inter-case dependencies, timing constraints, and explicit environmental needs are what distinguish it from the lighter-weight variants.
For automated cases, Template 1 is almost always correct. For highly visual or wizard-style UIs, Template 2 is easier to maintain. Template 3 is reserved for regulated environments where the case itself is a controlled document.
Take it with you
Download the piece you just read.
The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.
In the library
Pair this with.
Template · Test Plan
The test plan structure that actually gets read.
A test plan template that fits a sprint as comfortably as a multi-year program. Each section is there because a specific audience asks about it; each section is short enough to keep the whole plan under 20 pages.
Read →Process · The Master Framework
Four phases, applied in order, every project.
The top-level testing process used on every engagement. Four phases contain twelve sub-processes, each of which is documented in its own checklist in this library.
Read →Process · Test Execution
Run the tests, capture the data, adjust daily.
Test execution is where the risk register becomes results. These eight steps cover selection, assignment, the per-test inner loop, blocking-issue resolution, and the daily replanning that keeps a cycle on the rails.
Read →Process · Bug Reporting
Write bug reports developers act on.
A bug report is a sales document aimed at a developer. This is the ten-step sequence we use on every engagement to write reports that get fixed instead of dismissed.
Read →
Keep reading
Related reading
- Primer
Careers in Software Quality: Roles, Skills, and First Steps
What testers, test automation engineers, quality engineers, and test managers actually do, the skills each role uses, and practical first steps for students and career changers, including the ISTQB Foundation certification.
Read → - Primer
Errors, Defects, and Failures: What a Bug Really Is
Everyone says 'bug', but testers use three precise words: error, defect, and failure. Learn the difference, why it matters, and how severity and priority decide which problems get fixed first.
Read → - Primer
How Software Gets Attacked: Common Vulnerabilities in Plain English
The most common ways attackers break into software, explained without jargon: trusting input, broken access control, weak sign-in, misconfiguration, and outdated components. Each one comes with the defense that stops it.
Read → - Primer
How to Report a Bug So It Actually Gets Fixed
Finding a bug is half the job. Learn how to write a bug report a developer can act on: a clear summary, exact steps to reproduce, expected versus actual results, and the habits professional testers use to make every report count.
Read → - Primer
Security Testing Basics: Finding Weaknesses Before Attackers Do
An introduction to security testing for new testers and developers: thinking in threats, designing abuse cases, testing access control, the role of automated scanners and penetration tests, and the rules that keep security testing legal and ethical.
Read → - Primer
Staying Safe Online: Passwords, Sign-In, Phishing, and Updates
The everyday security habits that stop most attacks: strong unique passwords, multi-factor sign-in, spotting phishing, keeping devices updated, and sharing carefully. Written for students, families, and anyone starting out.
Read →
Practices
Where this leads
- QA & testingSoftware testing
Software quality consulting since 1994: we test the releases that matter, coach your team on the method, and measure how its testing matures.
Book a call →