Test Case Template

Download test case template (CSV)

A test case is a single, executable check. It has a starting state, steps, and an expected result that another person can judge without asking you what you meant.

If a “case” is only a title (“test login”), it is a reminder, not a test case. Reminders do not survive handover.

Download the CSV, or copy the field list below into your tracker.

What belongs in a test case

Field	Purpose
Test case ID	Stable handle (TC-101) for the RTM and bugs
Title	What is being checked, in one line
Requirement IDs	The row(s) this case covers
Type	Functional, negative, validation, regression, exploratory charter
Priority	Execution order when time is cut
Preconditions	What must already be true
Steps	Numbered, one action each
Expected result	Observable outcome, not “works fine”
Actual result / Status	Filled at execution, not at design
Owner	Who keeps it current

Leave Actual result empty in the template. Filling it during design is how stale cases pretend they were run.

How to write steps and expected results

• One action per step. “Open sign-in, enter credentials, and submit” is three steps.
• Name the object the tester must use: URL, role, field, button. “The usual account” is not a precondition.
• Expected results must be checkable: a URL, a message, a record created, a status code, a session cookie present or absent.
• Put data in the case or in a named data set. “Use a test user” is not data.

Exploratory work is allowed. Write it as a charter (“Spend 60 minutes trying to lock and unlock the account without a valid reset email”) with a mission and a time box, not as fake numbered steps you will not follow.

Good vs bad

Bad title: Test login Better title: Valid email and password sign the user in

Bad expected result: User should be able to login successfully Better expected result: User reaches the authenticated home state and a session is created

Bad step: Do the login process Better steps:

1. Open /sign-in
2. Enter a registered email and the correct password
3. Submit the form

Bad case: One case that covers sign-in, reset, lockout, and SSO Better: One case per behaviour, linked to the same requirement when they share one

The downloadable CSV includes three sign-in cases: valid sign-in, wrong password, empty password. That is the grain you want.

How to derive cases from a requirement

Do not brainstorm titles. Split the requirement, then write one case per split.

1. Happy path — the behaviour as specified, with valid data.
2. Obvious negatives — wrong password, empty field, expired link, unauthorized role.
3. Boundaries — first and last allowed values, max length, zero, “already used.”
4. State — the same action from a different starting point (already signed in, already locked, already invited).

If two cases differ by only one data value and the steps are identical, they can share a case with a small data table. If the expected result changes, they are different cases.

A review pass before execution: can a second tester run this without Slack? If not, the case is not finished. Check IDs against the RTM in the same pass so you do not invent orphans.

Naming

TC-101 Valid email and password sign the user in is searchable. TC-101 Login is not. Put the outcome in the title. Put the ID in the tracker key and in the title if your tool mangles keys in exports.

Never reuse an ID. If you delete a case, retire the ID. The matrix and old bug reports will still point at it.

How many cases

Enough to cover the requirement’s implied failures, not one case per pixel.

A sign-in requirement usually needs: valid credentials, wrong password, empty fields, locked account (if specified), and the information-disclosure rule. That is five cases, not fifty.

Add more when a failure mode is expensive (payments, permissions, data loss) or when a previous escape shows a hole. Do not add cases to make a count look serious. Coverage lives in the requirements traceability matrix, not in a vanity total.

Manual cases and automation

A good manual case is the specification an automated check should implement. If the case cannot be automated, that is fine — say so in Type or Notes. If it can be automated, do not rewrite it in a secret second format; keep the ID.

Automation without cases is a script graveyard. Cases without execution are a wiki. Test automation work we do still starts from cases like these, then decides which ones are worth running on every commit.

Where cases sit in the other documents

• The test plan says which sets run in this release
• The RTM lists the IDs against requirements
• A failed case becomes a bug report that points back at the case ID
• The test strategy says who is allowed to add or retire cases

Common mistakes

• Steps that assume a UI that changed last month and were never updated
• Expected results that describe intent (“should be secure”) instead of behaviour
• Copy-pasted cases with the wrong ID still in the title
• Mixing setup into every case instead of a shared precondition
• Marking a case Passed when a step was skipped

On manual and functional testing engagements, retiring dead cases is part of the work. A shorter accurate list beats a long one nobody trusts.

Related templates

• Requirements traceability matrix
• Test plan template
• Bug report template

If you want cases written from your stories and executed on a build, that is delivery work — contact us with the product and the next release.

FAQs

What is a test case template?

A standard set of fields so every check has an ID, preconditions, steps, and an expected result another tester can run.

Should every test case be automated?

No. Automate stable, high-value, repeatable checks. Leave brittle UI experiments and one-off investigations manual. See why test automation matters.

How detailed should steps be?

Detailed enough that a tester who knows the product domain but not this feature can run them. Not so detailed that a renamed button makes every case wrong in the same week.

Can I store cases only in Jira tickets?

Yes, if the fields still exist. A ticket that is only a title will fail the same way a blank spreadsheet row fails.

Do you write test cases from scratch?

Yes. We can start from requirements, stories, or a live product with little documentation. That is normal on functional testing work.