Test Case, Test Plan & User Story Template
Fill in a test case, test plan, or user story with Given/When/Then acceptance criteria. Copy as Markdown or plain text, or export CSV for import.
Open source on GitHubTest case details
One per line.
One per line.
One per line.
# Log in with valid email and password **ID:** TC-101 **Section:** Authentication **Priority:** High **Type:** Functional ## Preconditions - A verified user account exists - The user is logged out ## Test data - Email: qa.user@example.com - Password: (from the test vault) ## Steps | # | Step | Expected result | |---|------|-----------------| | 1 | Open the login page | The login form is shown with email and password fields | | 2 | Enter a valid email and password | Both fields accept the input; the password is masked | | 3 | Click “Log in” | The user lands on the dashboard within 3 seconds | ## Expected result The user is logged in and sees their dashboard. A session cookie is set. ## Postconditions - Log out to reset the session
What makes a good test case. Clear enough that anyone on the team gets the same result.
One clear outcome
Each test case checks one behavior with an expected result specific enough that two testers would agree on pass or fail.
Repeatable steps
Steps are short actions anyone on the team can follow, with preconditions and test data stated up front instead of assumed.
Traceable
An ID, a feature or section, and a link back to the user story or requirement make coverage and regressions easy to track.
Test case fields explained. What each column in the template is for.
| Field | Purpose | Example |
|---|---|---|
| ID | Unique reference used in test runs and bug reports | TC-101 |
| Title | What is being verified, in one line | Log in with valid email and password |
| Section / feature | Where the test lives in your suite | Authentication |
| Priority | How important the test is to run | High |
| Type | Kind of testing | Functional, regression, smoke |
| Preconditions | State the system must be in before step 1 | A verified account exists |
| Test data | Inputs used by the steps | qa.user@example.com |
| Steps | Numbered actions, each with its own expected result | Click “Log in” |
| Expected result | The overall outcome that means pass | The dashboard loads |
| Postconditions | Cleanup or resulting state after the test | Log out |
Scenarios, cases, criteria, and plans. How the documents fit together.
| Document | What it is | Example |
|---|---|---|
| Test scenario | A high-level situation to test, often one line | User pays with a saved card |
| Test case | Detailed steps, data, and expected results for one path through a scenario | TC-210: Pay with a saved Visa card |
| Acceptance criteria | Conditions a user story must meet to be accepted, often written as Given/When/Then | Given I have a saved card, when I pay, then the order is confirmed |
| Test plan | The scope, approach, environments, schedule, and exit criteria for a test effort | Checkout redesign test plan, v2.4 |
More free tools. Free, open source, no sign-up. See all tools · Source on GitHub
Frequently asked questions
What should a test case template include?
At minimum: an ID, a title, preconditions, test data, numbered steps with expected results, and an overall expected result. Priority, type, and the section or feature help you organize and filter cases in larger suites.
What is the difference between a test plan and a test case?
A test plan describes the whole testing effort: what is in and out of scope, the approach, environments, schedule, roles, risks, and entry and exit criteria. A test case is a single, specific check with steps and an expected result. One test plan usually covers many test cases.
How do I write acceptance criteria for a user story?
Use the Given/When/Then format: Given describes the starting context, When the action the user takes, and Then the observable outcome. Write one scenario per behavior, including failure paths, and keep each outcome testable.
Can I import these test cases into a test management tool?
Download the CSV. It has one row per test case with columns for ID, title, section, priority, type, preconditions, test data, steps, and expected result. Most test management tools let you map CSV columns to their own fields during import; check your tool’s import guide for required columns.
What happens when a test case fails?
Record the actual result, then file a bug report that references the test case ID, the steps, and the environment. A screen recording with console logs and network requests makes the failure much easier for a developer to reproduce.