How to Design Effective Manual Test Cases

A bad test case is worse than no test case. It takes time to write, time to maintain, and the false assurance that coverage exists where it doesn't.

Good test cases are precise enough to be executed consistently, brief enough to actually be read, and structured to catch what matters. Here's how to design them.

The Core Structure

Every test case needs six elements:

ID:          TC-001
Title:       Login with valid credentials — standard user
Preconditions: App installed, user account exists (test@example.com / Test@123)
Steps:
  1. Launch app
  2. Enter email: test@example.com
  3. Enter password: Test@123
  4. Tap "Sign In"
Expected Result: User lands on home screen, username shown in header
Priority:    High

No element is optional. Each does specific work:

• ID: Makes the test referenceable in bug reports and test runs
• Title: Tells you what's being tested without reading the steps
• Preconditions: Defines the exact starting state — the most common source of inconsistent results
• Steps: Specific enough to execute the same way every time
• Expected result: Defines pass/fail — without this, the test can't be evaluated
• Priority: Drives execution order when time is short

Writing Steps That Work

Be Action-Specific

Too vague: "Navigate to the settings page" Specific: "Tap the gear icon in the top-right corner of the home screen"

The specific version can be executed by anyone, including a new team member or an offshore tester. The vague version requires guessing.

One Action Per Step

Wrong (compound steps):

1. Launch the app and log in with test credentials and navigate to the profile page

Right:

1. Launch the app
2. Tap "Sign In"
3. Enter credentials: test@example.com / Test@123
4. Tap the "Sign In" button
5. Tap the profile icon in the bottom navigation

Compound steps make it impossible to pinpoint exactly where a failure occurred.

Include Test Data in Steps

Wrong: "Enter a valid email address" Right: "Enter email: test@example.com"

When test data is in the step, execution is consistent. When it's vague, every tester uses different data and results become unreproducible.

Expected Results: The Most Common Failure Point

Vague expected results make test cases useless.

Vague: "The login should work" Specific: "User is navigated to the Home screen. The username 'Test User' is displayed in the top-right header."

Vague: "An error should be shown" Specific: "A toast message appears: 'Invalid email or password. Please try again.' The password field is cleared. The email field retains its value."

The specific version leaves no ambiguity. Either the result matches or it doesn't.

[!TIP] Write expected results as if explaining to someone who has never seen the app and has no context. If they can verify the result without additional information, the expected result is specific enough.

Coverage: Positive, Negative, Boundary

Every feature should have test cases covering three categories:

Most QA engineers over-cover positive cases and under-cover negative and boundary cases. The bugs live in negative and boundary.

Test Case Maintenance

Test cases become outdated. A feature changes; the test case doesn't. Now the test passes or fails for the wrong reasons.

Maintenance practices:

• Review test cases when requirements change, not after
• Flag test cases as "needs review" when the feature is modified
• Delete test cases for features that no longer exist
• Don't accumulate test cases — a lean, accurate set beats a large, stale one

When to Write Detailed vs Lightweight Test Cases

Not all test cases need the same depth.

Detailed (full structure): Critical flows, compliance requirements, handoff testing, regression suite entries.

Lightweight (title + expected result only): Quick sanity checks, time-constrained testing, low-risk areas.

Lightweight example:
TC-042 | Upload profile photo | Photo displays correctly in profile header

This works for a tester who knows the product. It's not sufficient for handoff to a new team member or for compliance evidence.

Match the depth to the context. Over-documenting wastes time. Under-documenting breaks reproducibility.