Writing test cases is a foundational QA skill. Good test cases are clear enough that anyone can execute them and comprehensive enough to catch real bugs. Download our test case template to get started.
What is a Test Case?
A test case is a documented set of steps to verify a specific behavior of the software. It includes:
- A unique identifier
- A clear title describing what's being tested
- Preconditions (what must be true before starting)
- Step-by-step actions
- Expected result for each step
- Test data (specific inputs to use)
Test Case Template
TC-[Module]-[Number] Title: Clear description of what's being verified
Priority: High / Medium / Low
Preconditions: - Any setup required before executing
Test Data: - Specific values to use during testing
Steps: | Step | Action | Expected Result | |------|--------|----------------| | 1 | [What to do] | [What should happen] | | 2 | [What to do next] | [What should happen] |
Postconditions: - System state after test completes
Login Form — 15 Test Cases
Let's write test cases for a standard login form with email and password fields.
Positive Cases
TC-LOGIN-001: Successful login with valid credentials - Precondition: User has an active account - Steps: Enter valid email > Enter valid password > Click Login - Expected: Redirected to dashboard, welcome message shown
TC-LOGIN-002: Login with "Remember Me" checked - Precondition: User has an active account - Steps: Enter valid credentials > Check "Remember Me" > Click Login > Close browser > Reopen app - Expected: User is still logged in
TC-LOGIN-003: Password visibility toggle - Steps: Enter password > Click eye icon - Expected: Password characters become visible > Click again, they're hidden
Negative Cases
TC-LOGIN-004: Login with incorrect password - Steps: Enter valid email > Enter wrong password > Click Login - Expected: Error message "Invalid email or password" (don't reveal which field is wrong)
TC-LOGIN-005: Login with non-existent email - Steps: Enter unregistered email > Enter any password > Click Login - Expected: Same error message as wrong password (security best practice)
TC-LOGIN-006: Login with empty email - Steps: Leave email empty > Enter password > Click Login - Expected: Validation message "Email is required"
TC-LOGIN-007: Login with empty password - Steps: Enter email > Leave password empty > Click Login - Expected: Validation message "Password is required"
TC-LOGIN-008: Login with invalid email format - Steps: Enter "not-an-email" > Enter password > Click Login - Expected: Validation message "Please enter a valid email"
Security Cases
TC-LOGIN-009: Account lockout after failed attempts - Steps: Enter valid email > Enter wrong password 5 times - Expected: Account is locked, message shows "Too many attempts. Try again in 15 minutes"
TC-LOGIN-010: SQL injection attempt - Steps: Enter ' OR '1'='1 in email field > Click Login - Expected: Input is sanitized, normal error message shown, no data exposure
TC-LOGIN-011: XSS attempt - Steps: Enter <script>alert('xss')</script> in email > Click Login - Expected: Input is sanitized, no script execution
Boundary Cases
TC-LOGIN-012: Maximum length email - Steps: Enter email with 254 characters (RFC maximum) > Enter password > Click Login - Expected: System handles gracefully (accept or show clear error)
TC-LOGIN-013: Maximum length password - Steps: Enter password with 128 characters > Click Login - Expected: System handles gracefully
Usability Cases
TC-LOGIN-014: Tab navigation - Steps: Tab through form fields - Expected: Focus moves in logical order: email → password → remember me → login button
TC-LOGIN-015: Error message accessibility - Steps: Trigger validation error - Expected: Error message is associated with the input field (aria-describedby), screen reader announces it
Tips for Better Test Cases
Cover the four types
For any feature, write test cases across four categories:
- Positive: Normal usage that should work
- Negative: Invalid inputs that should be handled gracefully
- Boundary: Edge values at the limits of valid ranges
- Edge cases: Unusual but possible scenarios
Use the Given-When-Then format
Each test case follows a natural flow: - Given (precondition): the starting state - When (action): what the user does - Then (expected result): what should happen
Make tests independent
Each test case should work on its own without depending on other tests running first. This allows running tests in any order and makes failures easier to isolate.
Be specific with test data
Don't write "enter a valid email" — write "enter user@test.com". Specific data makes tests reproducible and reduces ambiguity.
One verification per test case
Each test case should verify one specific thing. If a test checks five different behaviors, a failure doesn't tell you which one broke.
How Many Test Cases Do You Need?
For a typical feature, aim for: - 3-5 positive cases (main flows) - 5-10 negative cases (invalid inputs, error handling) - 3-5 boundary cases - 2-3 edge cases - 2-3 security cases
That's roughly 15-25 test cases per feature. For interview purposes, writing 10-15 test cases for a login form demonstrates competence.
Practice Exercise
Choose a feature on any website — the search bar, the sign-up form, or the shopping cart. Write 15 test cases covering positive, negative, boundary, and security scenarios. Use the template above.
This is exactly what interviewers ask you to do. The more you practice, the faster and more thorough you'll become.