How to Write Test Cases: Step-by-Step Guide with Examples [2026]

A test case that does not catch the bug it was written to catch is not a test case. It is documentation.

The difference between a test case that reliably verifies behavior and one that gives false confidence is specificity. The more precisely a test case defines the input, the action, and the expected output, the more reliably it catches regressions and defects.

This guide walks through the complete process of writing effective test cases, from understanding the requirement to writing steps, handling edge cases, and reviewing for completeness.

What Makes a Good Test Case?

Before writing any test case, understand what separates effective ones from ineffective ones. A good test case is:

•       Specific: Each step has one clear action. Expected results are precise, not vague.

•       Repeatable: Any QA engineer can execute the test case and get the same result.

•       Independent: The test case does not rely on the state left by another test case.

•       Traceable: The test case links to a specific requirement or user story.

•       Complete: Preconditions, steps, test data, and expected results are all present.

Step-by-Step: How to Write a Test Case

Step 1, Understand the Requirement

Before writing a single test case, fully understand what the feature should do. Read the requirement or user story. Ask the product manager or developer to clarify any ambiguity. The test case can only be as accurate as your understanding of what the correct behavior is.

Common questions to answer before writing:

•       What is the happy path, the expected successful flow?

•       What are the failure conditions, wrong inputs, missing data, timeout?

•       What does the user see on success? On failure?

•       Are there boundary conditions, maximum values, minimum values, empty states?

•       Are there permissions or roles involved, what do different user types see?

Step 2, Identify Test Scenarios

A test scenario is a high-level description of what you are testing. Before writing detailed test cases, list the scenarios you need to cover:

•       Positive scenario: What happens when the user does everything correctly?

•       Negative scenarios: What happens with invalid input, wrong format, or missing required fields?

•       Boundary scenarios: What happens at the limits, maximum file size, maximum character count, zero items?

•       Permission scenarios: What can a non-admin user do that an admin can? What are they blocked from?

•       Error recovery: If the system returns an error, can the user recover without starting over?

For a login feature, the scenarios might be: successful login, login with wrong password, login with unregistered email, login with account locked, login with expired session, login with empty fields, login on mobile viewport.

Step 3, Write the Test Case Structure

Each test case should follow a consistent structure. In Trulit, this structure is built into the test case form. Here is the standard format:

EXAMPLE TEST CASE:

Test Case ID: TC-LOGIN-002

Title: Verify login fails with incorrect password

Priority: High | Severity: High

Preconditions: A valid user account exists with email 'testuser@trulit.com'. The user is on the login page (/login). No active session exists for this user.

Test Steps:

•       Navigate to https://app.trulit.com/login

•       Enter 'testuser@trulit.com' in the Email field

•       Enter 'WrongPassword123' in the Password field

•       Click the 'Log In' button

Expected Result: An error message is displayed: 'Incorrect email or password. Please try again.' The password field is cleared. The email field retains the entered email. The user remains on the login page.

Actual Result: [To be completed during execution]

Status: [Pass / Fail / Blocked]

Step 4, Write Specific, Actionable Steps

The most common failure mode in test case writing is vague steps. Compare these two versions:

Vague: 'Log in as a user and check the dashboard.'

Specific: '1. Navigate to /login. 2. Enter testuser@trulit.com in the Email field. 3. Enter TestPass123! in the Password field. 4. Click the Log In button. 5. Confirm that the URL changes to /dashboard and the text Welcome, Test User is visible in the top navigation.'

The vague version will produce different results from different testers. The specific version will produce the same result every time, regardless of who runs it.

Rules for writing steps:

•       One action per step.

•       Include specific input values, not placeholders like 'enter a valid email'.

•       Include the exact UI element to interact with, button label, field label, or page section.

•       Make the expected result measurable, 'the page shows a success message' is not measurable; 'the text Order Confirmed appears below the cart' is.

Step 5, Define Precise Expected Results

The expected result is the most important part of a test case. It is the definition of correct behavior. If the expected result is vague, a QA engineer cannot determine whether the test passed or failed.

Vague expected result: 'User should see an error.' Specific expected result: 'An inline validation error appears in red text below the Email field: This email address is not registered. Create an account? The Log In button is disabled until the email field is corrected.'

For every expected result, ask: could two different QA engineers look at the screen after this step and agree on whether it passed or failed? If the answer is 'maybe not', the expected result is too vague.

Step 6, Cover Edge Cases and Negative Scenarios

Happy-path test cases catch shallow bugs. Edge cases and negative scenarios catch the defects that reach production because nobody tested the boundary conditions.

For every feature, write at least these additional test cases:

•       Empty input: What happens if a required field is left blank?

•       Invalid format: What happens if the input format is wrong (e.g., letters in a phone number field)?

•       Maximum value: What happens when the input is at or beyond the maximum allowed value?

•       Minimum value: What happens at the lower boundary?

•       Duplicate: What happens if the user tries to create something that already exists?

•       Concurrent actions: What happens if two users try to edit the same record simultaneously?

•       Session expiry: What happens if the user's session expires mid-workflow?

Step 7, Review and Peer-Check Your Test Cases

Test cases should be reviewed by at least one other person before they are used in execution. The reviewer should ask:

•       Are the preconditions complete, can I set up the test environment from these alone?

•       Are the steps clear enough that I could execute them without asking any questions?

•       Is the expected result specific enough that I can make a pass/fail determination without judgment?

•       Is there an obvious scenario that this test case does not cover?

In Trulit, test cases can be submitted for peer review before they are added to an execution run. The review workflow creates a quality gate that catches weak test cases before they are used in a release.

Test Case Examples by Feature Type

Login / Authentication Test Cases

Typical test case count for a login feature: 8 - 12 cases. Must cover: successful login, wrong password, unregistered email, account locked, empty fields, forgot password flow, session persistence, concurrent logins, mobile viewport.

E-commerce Checkout Test Cases

Typical test case count: 20 - 35 cases. Must cover: successful checkout, payment failure, out-of-stock item, shipping calculation, promo code application, order confirmation email, inventory update after purchase, payment timeout, double-submit prevention.

API Endpoint Test Cases

Typical test case count: 5 - 15 per endpoint. Must cover: successful request with valid authentication, request with invalid token (expect 401), request with missing required parameter (expect 400), request that returns empty result (expect 200 with empty array, not 404), rate limit response (expect 429).

Common Test Case Writing Mistakes to Avoid

•       Writing test cases after development is complete. Write them from requirements, before code is written.

•       Using vague language like 'verify the system works correctly'. Always define what correct means in measurable terms.

•       Writing one test case per feature instead of one per scenario. Features have multiple scenarios; each needs its own test case.

•       Omitting preconditions. A test case without preconditions is a test case that will produce inconsistent results.

•       Not including test data. 'Enter a valid email' is not test data. 'Enter testuser@trulit.com' is.

•       Writing test cases in the first person ('I navigate to...'). Write in the imperative ('Navigate to...'). First person makes test cases harder to read in execution mode.

Internal links: /test-management-platform | /ai-test-case-generation | /blog/how-to-create-test-plan

Sources: ISTQB Foundation Level Syllabus, istqb.org | IEEE 829 Standard for Software Test Documentation | OWASP Testing Guide, owasp.org