Writing test cases is the bread and butter of Quality Assurance. But there’s a huge difference between a valid test case and an effective one.
An effective test case doesn’t just verify that a feature works; it communicates intent, provides a clear path to reproduction, and serves as living documentation for the system.
Here are my top rules for writing test cases that actually add value.
1. Keep It Atomic #
A single test case should verify a single behavior. If a test case title includes the word "and," you probably need to split it.
Bad:
Verify that the user can log in with valid credentials and then update their profile picture.
Good:
TC01:Verify user login with valid credentials.TC02:Verify profile picture update after successful login.
2. Preconditions Matter #
Never assume the tester (or future you) knows the state the system needs to be in. Explicitly state what needs to happen before step 1.
Example:
Precondition: User is registered, email is verified, and user is currently logged out.
3. Be Specific with Test Data #
Vague instructions lead to inconsistent testing. Don’t tell the tester to "enter a long string." Tell them exactly what to enter.
- Bad: Enter an invalid email address.
- Good: Enter an email address without an '@' symbol (e.g.,
testdomain.com).
4. The Expected Result is the Star #
The actual steps are just the vehicle to get to the expected result. The expected result must be crystal clear and verifiable.
Avoid subjective terms like "works correctly" or "looks good."
- Bad: The system should display an error.
- Good: The system displays a red toast notification with the exact text: "Invalid username or password."
5. Write for the "New Guy" #
The ultimate test of a good test case:
Can a brand new QA Analyst or Developer pick it up and execute it without asking you any questions?
If they can, you’ve written an effective test case.