A test case is a set of steps, data and an expected result used to check one specific behaviour of an application. Good test cases are clear enough that any tester can run them and get the same result.
Standard test case template
| Field | Purpose |
|---|---|
| Test Case ID | Unique ID, e.g. TC_LOGIN_001 |
| Title | What is being checked, in one line |
| Preconditions | What must be true before starting |
| Test Data | Exact inputs to use |
| Steps | Numbered actions |
| Expected Result | What should happen |
| Actual Result | What actually happened (filled during execution) |
| Status | Pass / Fail / Blocked |
| Priority | High / Medium / Low |
Example: login page
Requirement: A registered user can log in with email and password. After 5 wrong attempts the account is locked for 15 minutes.
Positive test case
- ID: TC_LOGIN_001
- Title: Login succeeds with valid email and password
- Preconditions: User
ravi@test.comis registered and active - Test Data: Email
ravi@test.com, PasswordValid@123 - Steps: 1. Open the login page. 2. Enter email. 3. Enter password. 4. Click Login.
- Expected Result: User lands on the dashboard and sees "Welcome, Ravi".
Negative test cases
| ID | Title | Test Data | Expected Result |
|---|---|---|---|
| TC_LOGIN_002 | Wrong password | Valid email, Wrong@1 | "Invalid email or password" shown, stays on login page |
| TC_LOGIN_003 | Unregistered email | nobody@test.com | Same generic error (does not reveal which field is wrong) |
| TC_LOGIN_004 | Empty fields | Both blank | Required-field messages, no request sent |
| TC_LOGIN_005 | Invalid email format | ravi@ | "Enter a valid email" |
| TC_LOGIN_006 | Lockout | 5 wrong passwords in a row | Account locked message; correct password also rejected for 15 min |
A good tester spends more time on negative and edge cases than on the happy path. Most real bugs live there.
Test design techniques
Boundary Value Analysis (BVA)
Errors happen at the edges. If a password must be 8 to 16 characters, test:
| Length | Expected |
|---|---|
| 7 | Rejected |
| 8 | Accepted |
| 16 | Accepted |
| 17 | Rejected |
Equivalence Partitioning
Group inputs that should behave the same and test one value from each group. For an age field accepting 18 to 60: one value below 18, one between 18 and 60, one above 60.
Decision Table
Use when the result depends on combinations of conditions, for example "discount applies only if the user is a student AND pays in full".
Tips for writing great test cases
- One test case checks one thing.
- Write steps a new joiner can follow without asking questions.
- Make expected results specific: "Error shown" is weak; "Red text 'Invalid email or password' below the form" is strong.
- Link each test case to a requirement ID so you can show coverage (a traceability matrix).
- Keep test data realistic but never use real customer data.
Using AI to speed up test design
AI tools can draft test cases from a requirement in seconds. Paste the requirement and ask for positive, negative and boundary cases in a table. Then review every case: AI often misses business rules and invents behaviour that is not in the requirement. The tester remains responsible for coverage.
Interview questions
- Test case vs test scenario? A scenario is a high-level "what to test" (e.g. "Verify login"); test cases are the detailed steps for each variation.
- What is a traceability matrix? A table mapping requirements to test cases, used to prove every requirement is tested.
- Severity vs priority? Severity is the impact of a bug on the system; priority is how soon it must be fixed.
Next steps
Practise by writing 15 test cases for a "Forgot password" feature. Then learn automation with Selenium, or join the Manual Testing + AI course.