A test case is a documented set of actions, data and expected outcomes used to verify that a feature works correctly. Written well, test cases help a team test consistently, uncover defects and communicate clearly. Written badly, they waste everyone’s time.
This is a practical, beginner-friendly guide to writing test cases that actually earn their place — the parts that matter, a worked example, and the habits that separate useful cases from box-ticking.
Free companion download
Writing a Good Test Case Guide (PDF) · 3.3 MB
Why good test cases matter
- They improve coverage of the scenarios that matter.
- They reduce ambiguity between testers and developers.
- They make regression testing repeatable.
- They provide evidence of what was tested.
- They help junior testers learn structured thinking.
The 7 parts of a strong test case
- 1
Test Case ID
A unique reference, such as LOGIN-001.
- 2
Title
A clear statement of what is being tested.
- 3
Preconditions
What must already be true before execution.
- 4
Steps
The exact actions the tester performs.
- 5
Test Data
The specific values used in the test.
- 6
Expected Result
What should happen if the system works.
- 7
Status / Actual Result
Pass, Fail or Blocked — plus notes on what actually happened.
A worked example
- ID: LOGIN-001
- Title: Verify a user can log in with valid credentials.
- Preconditions: A registered account exists.
- Steps: 1) Open the login page. 2) Enter a valid email. 3) Enter the password. 4) Click Login.
- Test Data: qa@test.com / Password123
- Expected Result: The user is redirected to the dashboard.
Notice how little is left to interpretation. Anyone on the team could run this, get the same result, and know immediately whether it passed.
Beginner mistakes to avoid
- Too vague — "Check checkout works" tells no one what to actually do.
- Too much detail — documenting every tiny mouse movement.
- Missing the expected result, so pass or fail is a matter of opinion.
- Testing too many objectives in one case.
- Unclear titles that do not say what is being verified.
How to think like a tester
Good test cases come from good questions. As you write, keep asking: what matters most to the user? What could fail? What data should I try? What result would prove success? Focus on clarity, coverage and risk — not volume.
Practice exercise
Write five test cases for a shopping basket page, covering a positive scenario, a negative scenario, a boundary case, a usability check and an error-handling case. Modern teams may use checklists, scenarios, BDD or exploratory notes instead of heavyweight cases — but clear thinking still wins, whatever the format.
Key takeaways
- A strong test case has seven parts — and always a clear expected result.
- Write for clarity: anyone should be able to run it and get the same result.
- Avoid vagueness, over-documentation and testing several objectives at once.
- Great test cases come from good questions about risk, coverage and the user.
Frequently asked questions
What are the parts of a good test case?
A strong test case has seven parts: a unique Test Case ID, a clear Title, Preconditions, Steps, Test Data, an Expected Result, and a Status / Actual Result. The expected result is the part beginners most often miss — without it, pass or fail becomes a matter of opinion.
How do you write a test case for beginners?
Start with a clear title that says what you are verifying, note any preconditions, list exact steps and the specific test data, and state the expected result. Keep each case focused on one objective, and make it clear enough that anyone could run it and get the same result.
What is an example of a test case?
A simple example: ID LOGIN-001, "Verify a user can log in with valid credentials"; precondition "a registered account exists"; steps to open the login page, enter a valid email and password and click Login; test data qa@test.com / Password123; expected result "the user is redirected to the dashboard".