A test case is a documented set of conditions, steps, and expected results used to verify that a feature works correctly. Well-written test cases are the foundation of repeatable, auditable quality assurance — they let any tester execute the same verification and reach the same conclusion.

Standard Test Case Format

Every effective test case contains these elements:

• Test Case ID — unique identifier (e.g. TC-LOGIN-001)
• Title — one-line summary of what is being verified
• Preconditions — the state required before execution (e.g. "user account exists, user is logged out")
• Test Steps — numbered, specific actions
• Test Data — the inputs used (usernames, amounts, file names)
• Expected Result — the verifiable outcome that defines pass/fail
• Priority — critical / high / medium / low

Example: Login Test Case

TC-LOGIN-001 — Successful login with valid credentials

1. Navigate to the login page
2. Enter a registered email in the email field
3. Enter the correct password
4. Click the "Log in" button

Expected result: User is redirected to the dashboard within 3 seconds; the header shows the user's name; no error messages appear.

7 Rules for Writing Better Test Cases

1. One objective per test case — if a test verifies five things, a failure tells you almost nothing about what broke
2. Write steps a stranger could follow — avoid "verify it works"; specify exactly what to click and check
3. Make expected results measurable — "page loads quickly" is not verifiable; "page loads within 2 seconds" is
4. Cover negative paths — wrong password, empty fields, expired sessions, special characters
5. Include boundary conditions — minimum and maximum lengths, zero values, off-by-one cases
6. Keep test data explicit — reference the exact accounts, amounts, and inputs used
7. Link to requirements — traceability shows what coverage you have and what is missing

From Manual Test Cases to Automated Tests

A well-written manual test case translates almost directly into an automated test: steps become actions, expected results become assertions. Tools like TestInspector close this gap completely — you describe the test steps in plain English and the AI generates an executable automated browser test. See our manual vs automated testing guide for when each approach fits.

Common Test Case Mistakes

• Vague steps that produce inconsistent execution between testers
• Missing preconditions causing false failures
• Testing implementation details instead of user-facing behaviour
• No negative or edge-case coverage — happy-path-only suites miss most real bugs

Frequently Asked Questions: Writing Test Cases

What is the difference between a test case and a test scenario?
A test scenario is a high-level situation to verify ("user can purchase a product"). A test case is the detailed, step-by-step verification of one path through that scenario.

How many test cases does a feature need?
Enough to cover the happy path, all major error paths, and the boundary conditions. A simple login feature typically needs 8–15 test cases.

Should test cases be written before or after development?
Before or during — writing test cases from requirements (not from the built UI) catches requirement gaps early and avoids testing only what was built.

What tools are used to manage test cases?
Common options include TestRail, Zephyr, Azure Test Plans, and Xray. For automated browser tests, TestInspector stores tests as structured steps with built-in scheduling and reporting.

Want professionally designed test coverage for your application? Contact Astaqc Consulting.