Test cases are the most visible output of a manual tester. When a lead reviews your work, when a new team member executes your suite, or when an interviewer asks you to "write test cases for a login page", the quality of your test cases is what they judge. In this lesson you will learn the standard template used in Indian IT companies and product startups, the qualities that separate a professional test case from a vague one, and you will walk through a complete worked example.
What Is a Test Case?
A test case is a documented set of preconditions, test data, steps and an expected result that checks one specific behaviour of the application. A test scenario (from the previous lesson) says what to test, for example "Verify login functionality". Test cases say how to test it, one condition at a time. One scenario usually produces several test cases.
Standard Test Case Template
Tools differ (Excel, TestRail, Zephyr, Xray for Jira), but almost every organisation uses the same core fields:
| Field | Purpose | Example |
|---|---|---|
| Test Case ID | Unique identifier for tracking and reporting | TC_LOGIN_001 |
| Module / Feature | Groups related test cases | Login |
| Requirement ID | Links the case to the RTM for traceability | REQ-AUTH-01 |
| Title | One line describing the condition being verified | Verify login with valid mobile number and password |
| Preconditions | What must be true before you start | User is registered; app is installed |
| Test Data | Exact input values to use | Mobile: 9876543210, Password: Test@1234 |
| Test Steps | Numbered actions to perform | 1) Open app 2) Enter mobile 3) Enter password 4) Tap Login |
| Expected Result | The exact, observable correct behaviour | Home dashboard opens showing "Welcome, Priya" |
| Actual Result | What actually happened during execution | Filled during execution |
| Status | Outcome of execution | Pass / Fail / Blocked / Not Run |
| Priority | Order of execution when time is short | High |
| Type | Nature of the check | Functional, Negative, UI, Security |
| Remarks / Defect ID | Notes or the linked bug when failed | BUG-1042 |
When asked "What are the fields of a test case?", list them in execution order: ID, title, preconditions, test data, steps, expected result, actual result, status. Then mention traceability fields such as Requirement ID and Defect ID. This shows you understand the purpose, not just the names.
Characteristics of a Good Test Case
- Atomic: verifies one condition only, so a failure points to one cause.
- Clear and simple: any tester, even someone who joined yesterday, can execute it without asking questions.
- Specific expected result: states exactly what should appear, including message text, page name or value.
- Independent: does not depend on another test case having run first.
- Repeatable: gives the same result every time with the same data and build.
- Traceable: mapped to a requirement or user story.
- Maintainable: written at the right level of detail, so small UI changes do not force a full rewrite.
Positive and Negative Test Cases
Positive test cases use valid inputs and confirm the system does what it should. Negative test cases use invalid inputs or unexpected actions and confirm the system handles them gracefully, with a clear message and no crash or data corruption. In real projects, negative cases often outnumber positive ones, because there are many more ways to use software wrongly than correctly. Combine them with the techniques you already learned: equivalence partitioning and boundary value analysis give you the exact invalid values to try.
Worked Example: Login Page
Requirement REQ-AUTH-01: A registered user logs in to a banking app with a 10-digit mobile number and a password of 8 to 16 characters. Wrong credentials show "Invalid mobile number or password". After 3 consecutive wrong passwords, the account is locked for 30 minutes. The password field is masked and has a "Show" toggle.
| ID | Title | Test Data | Expected Result | Type |
|---|---|---|---|---|
| TC_LOGIN_001 | Login with valid mobile and valid password | 9876543210 / Test@1234 | Dashboard opens with "Welcome, Priya"; session starts | Positive |
| TC_LOGIN_002 | Login with valid mobile and wrong password | 9876543210 / Wrong@123 | "Invalid mobile number or password" shown; user stays on login page | Negative |
| TC_LOGIN_003 | Login with unregistered mobile number | 9123456780 / Test@1234 | Same generic error as TC_LOGIN_002; app does not reveal that the number is unregistered | Negative, Security |
| TC_LOGIN_004 | Login with both fields blank | Blank / Blank | Login button disabled, or "This field is required" under each field | Negative |
| TC_LOGIN_005 | Mobile number with 9 digits | 987654321 / Test@1234 | "Enter a valid 10-digit mobile number"; no request sent | Negative, BVA |
| TC_LOGIN_006 | Password with 7 characters | 9876543210 / Test@12 | Validation message for minimum 8 characters | Negative, BVA |
| TC_LOGIN_007 | Account lock after 3 wrong attempts | 3 x wrong password | "Account locked for 30 minutes" after the third attempt; correct password also rejected during lock | Negative |
| TC_LOGIN_008 | Password masked with Show toggle | Test@1234 | Characters masked by default; visible after tapping Show; masked again on second tap | Positive, UI |
TC_LOGIN_007 | Precondition: user 9876543210 is registered and not locked. Steps: 1) Open the login page. 2) Enter 9876543210 and Wrong@111, tap Login. 3) Repeat with Wrong@222. 4) Repeat with Wrong@333. 5) Enter the correct password Test@1234 and tap Login. Expected: steps 2 and 3 show the generic error; step 4 shows "Your account is locked for 30 minutes"; step 5 is rejected with the lock message.
Notice how each row checks exactly one condition, uses concrete data and states a verifiable result. Boundary values (9 digits, 7 characters) come straight from BVA; the lock rule comes from state transition thinking.
Common Mistakes to Avoid
- Vague expected results such as "Login should work properly". Always describe the exact screen, message or value.
- Combining many checks in one case, for example login, profile edit and logout together. When it fails, nobody knows which part broke.
- Missing test data, which forces the executor to invent values and makes results unrepeatable.
- Hidden dependencies such as "use the order created in TC_045".
- Too much or too little detail: "Move the mouse to the button" is noise; "Test the page" is useless.
- Ignoring negative and boundary cases, where most real defects hide.
- Not updating cases after a requirement change, leaving the suite out of date.
Copy-pasting a test case and forgetting to change the title or expected result is one of the most common review comments freshers receive. Re-read every case you clone.
