Lesson 1 of 104 min read
What makes a good test case
A good test case can be run by anyone and always gives the same, clear result.
Key takeaways
- 1Parts: ID, title, preconditions, steps, test data, expected result.
- 2One test case checks one thing. Titles should say what is checked.
- 3Expected results must be specific: not 'works fine', but 'Dashboard page opens with the user's name'.
Real example
TC-01 Login with valid credentials Precondition: user test@mail.com exists Steps: 1. Open /login 2. Enter email and password 3. Click Login Expected: Dashboard opens and shows 'Welcome, Test'.
Go deeper
Expert notes beyond the basics
- 01
The stranger test
Hand your test case to someone who has never seen the app. If they can run it and decide pass or fail without asking you a single question, it is a good test case. If they need to ask 'which user?' or 'what should I see?', the preconditions or expected result are missing.
- 02
Atomic, but not tiny
One test case should verify one behaviour, so a failure points to one problem. But don't split every click into its own case. 'Login with valid credentials' is one case even though it has four steps.
- 03
Write for re-use
Good cases survive releases. Avoid things that change often, like exact prices or today's date, unless that is the point of the test. Put changeable values in the Test data column, not inside the steps.
Common mistakes to avoid
- - Expected results like 'should work' or 'page loads properly' that nobody can fail.
- - Hiding test data inside steps, so the case breaks when the data changes.
- - Combining login, search and checkout in one giant case, so one failure blocks everything.
Try it yourself
Rewrite this weak test case so a stranger could run it: 'Check signup works.'
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
What fields does a test case have?
Model answer
Test case ID, title, preconditions, steps, test data, expected result, and actual result/status during execution. Often also priority and linked requirement.
- Q2
What is the difference between a test scenario and a test case?
Model answer
A scenario is a one-line idea of what to test, such as 'User logs in with wrong password'. A test case is the detailed version: preconditions, data, exact steps and expected result. Scenarios give coverage quickly; test cases make execution repeatable.
- Q3
How many test cases do you write per day?
Model answer
It depends on complexity, but I avoid quoting a number as a target. For a medium feature I might design 20-40 cases a day including review. Quality and coverage of risk matter more than count.
Knowledge check
+5 points
Which expected result is best?