Writing good test cases is about being clear, specific, and testable so that anyone (not just you) can execute them and verify results without confusion.
Here’s a step-by-step approach:
1. Understand the Requirements
-
Read the SRS (Software Requirements Specification), user stories, or acceptance criteria.
-
Identify what needs testing (features, inputs, flows).
-
Clarify any unclear points before writing.
2. Use a Standard Test Case Structure
A simple and widely used format is:
| Field |
Description |
| Test Case ID |
Unique identifier (e.g., TC_LOGIN_001). |
| Title |
Short, descriptive name of the test. |
| Description |
What the test is verifying. |
| Preconditions |
Setup or conditions needed before running the test. |
| Test Steps |
Step-by-step actions to perform. |
| Test Data |
Specific inputs required. |
| Expected Result |
What should happen if the system works correctly. |
| Actual Result |
Filled in after execution. |
| Status |
Pass/Fail/Blocked (filled after execution). |
| Remarks |
Notes about the test. |
3. Writing Guidelines
-
Be clear and concise — avoid vague words like “check” or “verify” without detail.
-
One purpose per test case — don’t mix unrelated verifications.
-
Use consistent naming — easy to search/filter later.
-
Make them independent — one test case shouldn’t depend on another.
-
Cover positive and negative scenarios — test valid and invalid inputs.
4. Example Test Case
Test Case ID: TC_LOGIN_001
Title: Login with valid credentials
Description: Verify user can log in successfully with correct username and password.
Preconditions: User account exists and is active.
Test Steps:
-
Navigate to the login page.
-
Enter a valid username.
-
Enter the correct password.
-
Click on the “Login” button.
Test Data:
-
Username: [email protected]
-
Password: Password123
Expected Result: User is redirected to the dashboard page and sees a welcome message.
Actual Result: (To be filled after execution)
Status: (Pass/Fail)
Remarks: (Optional notes)
5. Common Mistakes to Avoid
-
Writing overly generic steps like “Login to the system” without saying how.
-
Not specifying expected results in measurable terms.
-
Combining multiple flows into one test case.
-
Forgetting edge cases (empty inputs, invalid formats, max/min values).