Software Test Case Templates and Examples

A test case template should remove ambiguity, not create paperwork. At minimum, it must tell the tester what is being checked, which conditions and data are required, what actions to perform, and what observable result counts as a pass.

Below are three copy-ready templates for different levels of detail, followed by completed web, API, mobile, and regression testing examples. You will also see which fields belong to the reusable test case and which should only be recorded during a specific test run.

Copy a software test case template

Basic test case template

Use this version for straightforward functional checks and small teams.

This format is compact, but it still provides enough information to repeat the test without relying on the author’s memory.

Detailed step-by-step test case template

Use this template when the workflow is complex, several people may execute the test, or you need step-level evidence and traceability.

TestRail and Azure Test Plans support this structure, including a separate expected result for each step. This makes it easier to identify exactly where a test failed and link the failure to a defect or requirement.

BDD test case template

BDD works well when product, development, and QA teams want to describe behavior using the same language.

Feature: [Feature name]

  Scenario: [Behavior being verified]
    Given [initial state or precondition]
    And [additional context]
    When [event or user action]
    Then [observable expected outcome]
    And [additional expected outcome]

For the same scenario with several data combinations, use a Scenario Outline:

Feature: User authentication

  Scenario Outline: Login with invalid credentials
    Given an active user account exists
    When the user signs in with "<email>" and "<password>"
    Then access is denied
    And the user sees "<message>"

    Examples:
      | email                                    | password          | message                                     |
      | unknown@example.test  | ValidPass!42     | Incorrect email or password  |
      | qa.user@example.test     | WrongPass!42  | Incorrect email or password  |

In Gherkin, Given establishes the initial state, When describes an event or action, and Then defines an observable result. The official Cucumber reference recommends keeping scenarios focused enough to remain readable as specifications, not turning them into transcripts of every interface interaction.

Which test case template should you use?

More fields do not automatically produce better tests. Choose the level of detail based on risk, team structure, and the purpose of the test.

A ten-step case may be appropriate for a regulated healthcare workflow and excessive for checking a low-risk filter. The template should preserve the test’s intent without making routine execution unnecessarily slow.

What is a test case?

A test case is a documented set of conditions, inputs, actions, and expected results used to verify a specific behavior of a system. The ISTQB glossary describes a concrete test case through preconditions, input data, expected results, postconditions, and actions where applicable.

Several related QA artifacts are easy to confuse:

A test suite is not the same as a test plan. A suite groups test cases; a test plan defines scope, objectives, resources, environments, schedules, risks, and the overall testing approach.

What should a test case include?

Not every field belongs to the test case itself. Some describe the reusable test specification; others record the outcome of a particular execution.

Core test case fields

Optional fields

Depending on the project, a test case may also include:

• module or feature;

• test type;

• environment or configuration;

• postconditions;

• dependencies;

• tags;

• automation status;

• owner;

• attachments;

• supported browsers, devices, or operating systems.

Optional fields should solve a real coordination or traceability problem. If a field is consistently empty or ignored, it probably does not belong in the template.

Test execution fields

These values change from one run to another:

• actual result;

• Pass, Fail, Blocked, or Skipped status;

• tester;

• execution date;

• application build;

• environment used;

• screenshots, logs, or other evidence;

• linked defect ID.

The distinction matters. An expected result is defined while the test is authored. An actual result records what happened during execution. Azure Test Plans follows this model and stores actual results as part of the test run.

Putting a permanent Status: Passed field into the reusable specification creates confusion. The same case may pass in one build, fail in the next, and be blocked in a third environment.

How to write a good test case

1. Start with one behavior

A test case should answer one focused question. “Verify the entire account area” is too broad. “Verify that a user can change a valid password” gives the tester a clear objective and produces an unambiguous result.

This does not mean every test must contain one assertion. Several observations can belong together when they describe one business outcome. For example, a successful checkout may need to verify the displayed total, order creation, payment confirmation, and inventory update.

2. Link the case to a requirement

A requirement, acceptance criterion, or business rule explains why the test exists. Traceability helps the team identify:

• requirements without tests;

• tests whose requirements have changed;

• obsolete cases;

• the impact of a proposed product change.

If there is no written requirement, document the source of truth: an approved design, API contract, compliance rule, or confirmed product decision.

3. Define the starting state

“Open the checkout page” is not enough if the user must already be authenticated, have a product in the cart, and belong to a specific pricing region.

Useful preconditions may cover:

• account state and permissions;

• existing data;

• feature flags;

• application build;

• browser or device configuration;

• integration availability;

• network state.

Do not hide critical preconditions inside the first few test steps.

4. Use controlled test data

“Enter a valid email” leaves the tester to invent data and may produce different outcomes across runs. Specify a fictional test account or explain how to generate one.

Never place production passwords, access tokens, payment details, or personal information in a test case. Use synthetic data and designated test environments.

5. Make each step actionable

A step should describe a clear action in execution order. Avoid combining several unrelated actions into one sentence.

At the same time, do not make the case unnecessarily brittle. “Select the account menu and open Profile” will survive minor layout changes better than an instruction based on pixel position, color, or an icon that may soon be redesigned.

6. Write observable expected results

An expected result must provide a clear basis for Pass or Fail.

Avoid phrases such as “works correctly,” “as expected,” or “successful” unless the sentence also defines what correct behavior looks like.

7. Set priority by risk

Priority should reflect business impact, likelihood of failure, and how often users encounter the behavior.

A checkout failure normally deserves more attention than a minor formatting inconsistency. Priority is not the same as defect severity: priority orders work, while severity describes the impact of a failure.

For a more detailed authoring process, see DeviQA’s guide on how to write test cases.

Complete software test case examples

The following examples use fictional requirements and data. Their expected results illustrate a possible product specification, they are not universal rules for every application.

Example 1: Positive web login test case

The actual result, status, execution date, and evidence should be added during the test run rather than stored as permanent values in this case.

Example 2: Password boundary test cases

Assume a fictional requirement states that a password must contain between 8 and 64 characters. Boundary value analysis concentrates checks around those limits.

This is more useful than creating dozens of nearly identical cases with arbitrary password lengths. It verifies the values most likely to expose an off-by-one error.

Do not invent restrictions that do not exist in the requirement. If the specification does not prohibit spaces or particular symbols, the test case should not assume that it does.

Example 3: E-commerce checkout with a discount code

“Order completed successfully” would be too vague here. The expanded result can reveal discount, shipping, payment, persistence, and notification inconsistencies within the same business flow.

For more complex journeys, see these E2E test case templates and examples.

Example 4: API test case

Assume the fictional API contract defines POST /v1/users as the endpoint for creating a user.

Expected result:

• HTTP status is 201 Created;

• the response contains a non-empty user ID;

• email, name, and role match the request;

• no password, token, or other sensitive field is returned;

• requesting the created user by ID returns the stored record.

A negative sibling case can reuse the setup but submit an existing email:

Do not assume that every API must return 409 Conflict for duplicates. The expected code must come from the actual API contract.

Example 5: Mobile app behavior when connectivity is lost

Mobile test cases should identify the relevant device, operating system, permission, orientation, and connectivity conditions without duplicating the same business logic for every device combination. Use configurations or parameters where possible.

Example 6: The same business rule in Gherkin

Feature: Checkout discounts

  Rule: An active percentage discount applies only to eligible items

    Scenario: Apply a valid 20% discount to an eligible item
      Given a signed-in user has an eligible $100 item in the cart
      And the discount code "SAVE20" is active
      And shipping costs $5
      When the user applies the discount code
      Then the item discount should be $20
      And the checkout total should be $85
      And the applied code should appear in the order summary

The BDD version is easier to discuss with non-technical stakeholders. The detailed test case remains more useful when execution requires precise data, environment settings, or step-level evidence. Teams can use both formats without duplicating every implementation detail.

Test design techniques that improve a template

A template standardizes documentation. It does not decide what should be tested. That requires test design.

A neat template filled with weak scenarios still produces weak coverage. Start with the business rule and its risks, then select the test data and format.

Test case, checklist, or automated test?

Detailed cases are useful, but they are not the only valid form of test documentation.

Use a detailed test case when:

• the workflow is complex or high-risk;

• setup and data are not obvious;

• another person must reproduce the test;

• evidence and traceability are required;

• the test supports acceptance or compliance work.

Use a checklist when:

• the tester already understands the feature;

• the interface changes frequently;

• fast exploratory feedback matters more than repeatable steps;

• the risk does not justify detailed documentation.

Consider automation when:

• the behavior is stable;

• the test is repeated frequently;

• execution is time-consuming or data-heavy;

• results can be checked reliably;

• fast regression feedback has business value.

Automation does not eliminate the need for test design. It changes the executable form of the check. Manual, exploratory, and automated coverage should complement one another.

How to maintain test cases at scale

A suite that nobody maintains gradually becomes a record of how the product used to work.

Use a consistent naming convention

A practical ID can include the module and behavior:

• AUTH-LOGIN-001;

• CHK-PAYMENT-012;

• MOB-SYNC-007.

The identifier should remain stable even if the title changes.

Parameterize repeated checks

If five cases have the same setup and steps but different input values, a data-driven case may be easier to review and maintain. TestRail, Azure Test Plans, and other test management tools support parameters, reusable steps, configurations, or imports.

Tag cases by execution purpose

Useful tags may include:

• smoke;

• critical regression;

• platform;

• integration;

• feature;

• risk;

• automation status.

Do not create so many tags that nobody applies them consistently.

Assign ownership

Someone must decide when to update, archive, or split a case. Ownership can be assigned by feature, test suite, or product area rather than to every individual case.

Review the suite after requirement changes

A change can affect more than the cases directly linked to a feature. Review downstream integrations, permissions, reports, notifications, and regression flows as well.

Signs that a suite needs cleanup include:

• several cases verify the same behavior;

• expected results contradict the current product;

• testers repeatedly ask how to prepare the data;

• most of the suite is skipped;

• a minor UI change requires hundreds of edits;

• cases have no link to active requirements;

• nobody can identify the critical regression set.

What large QA projects teach us about test cases

More test cases do not automatically mean better coverage. Relevance, maintainability, and execution strategy matter more than the raw count.

In DeviQA’s work on a glucose monitoring ecosystem, the initial QA process included outdated test cases, 50% coverage, and a regression cycle that took 2.5 weeks. The updated process increased test coverage to 90%, expanded the number of relevant regression tests, and used automation to reduce regression execution to one day.

The useful lesson is not that every project needs thousands of cases. It is that the suite must evolve with the product. Stable repetitive checks are strong automation candidates, while manual QA time can shift toward new functionality, exploratory work, and keeping documentation current.

A separate cybersecurity platform project grew to more than 1,200 test cases and 90% test coverage. AI tools were incorporated into the workflow to assist with test case creation, test data, and bug reporting. At that scale, consistent structure and human review become more valuable, not less.

Using AI to draft test cases

AI can reduce the time spent on a first draft. Given an approved requirement, it can help:

• identify positive, negative, and boundary scenarios;

• propose synthetic test data;

• convert a table into Gherkin;

• reformat cases for another tool;

• find similar or potentially duplicated cases;

• suggest questions about incomplete acceptance criteria.

It cannot determine the product’s intended behavior when the source requirement is missing or contradictory. An authoritative-looking expected result can still be entirely wrong.

Before accepting an AI-generated test case:

Production credentials, customer information, health records, financial data, and confidential specifications should not be pasted into an unapproved AI service.

Common test case mistakes

1. Vague expected results

“Works correctly” gives the tester nothing to compare. Describe the visible response, returned data, state change, or prevented action.

2. Several unrelated behaviors in one case

A case that verifies registration, login, profile editing, and account deletion is difficult to diagnose and reuse. Split it unless the purpose is explicitly to test that end-to-end journey.

3. Missing preconditions

If the account role, data state, or configuration affects the outcome, document it before the first step.

4. Improvised test data

Different inputs can follow different code paths. Use known synthetic values or define a safe generation rule.

5. Copy-paste without review

Copied cases often retain an old module name, account role, requirement ID, or expected result. Parameterization and shared steps reduce this maintenance risk.

6. Confusing priority and severity

Test priority determines what to execute first. Defect severity describes the impact of a discovered problem.

7. Storing execution status in the reusable case

Pass or Fail belongs to a run. Keeping a permanent status in the case hides differences between builds and environments.

8. Excessive detail

Instructions such as “move the cursor” or “use the left mouse button” make tests longer without improving reproducibility. Document meaningful actions and decisions.

9. No retirement process

Obsolete cases increase execution and review costs. Archive them with history rather than leaving them in the active regression suite.

A useful template is deliberately selective

The best software test case template is not the one with the most columns. It is the one that preserves the purpose of the test, controls the conditions that affect it, and makes the expected behavior clear enough to produce the same decision across different testers and runs.

As the product grows, the format should also support traceability, reuse, maintenance, and automation. If the suite becomes expensive to execute or difficult to trust, adding more cases will not solve the problem. The team first needs to improve how cases are designed, organized, and retired.

If you need help creating a test suite, reviewing existing coverage, or replacing outdated QA documentation, DeviQA’s manual testing services can help align test cases with product risks, requirements, and release workflows.

Keep quality steady as you scale

Schedule a call

Frequently asked questions

What is a test case template?

A test case template is a reusable structure for documenting a test’s objective, preconditions, data, actions, and expected results. It helps different team members describe and execute tests consistently.

Which fields are mandatory?

Most functional test cases need an ID, title, preconditions, test data, steps, expected result, and priority. A requirement reference is strongly recommended when traceability matters. Additional fields should be added only when they support execution, reporting, or maintenance.

What is the difference between a test case and a test scenario?

A test scenario identifies what should be tested, such as “password recovery.” A test case defines a specific verification, including setup, data, actions, and expected behavior, such as recovering an account with a valid unexpired link.

Should every step have an expected result?

No. Add a step-level expected result when the system should produce something that must be verified at that point. Pure navigation or setup steps may not require one. A single final expected result may be enough for a short case.

What is the difference between expected and actual results?

The expected result is defined before execution and describes the passing behavior. The actual result is recorded during a test run and describes what the system did. The comparison determines whether the test passed or failed.

How detailed should a test case be?

It should contain enough information for the intended tester to reproduce the check without guessing about critical conditions or results. High-risk, regulated, or externally executed tests usually require more detail than low-risk checks performed by an experienced product team.

Can test cases be managed in Jira?

Yes, but the implementation varies. Teams may create a custom Jira issue type or use a test management integration such as Xray. Dedicated tooling becomes more useful when the team needs test runs, reusable steps, requirement coverage, execution history, and structured reports.

Is Excel suitable for test case management?

Excel or Google Sheets can work for a small project, an MVP, or an initial test inventory. They become harder to manage when many testers execute cases in parallel or the team needs detailed history, permissions, integrations, and traceability.

What is a BDD test case?

A BDD test case describes behavior through examples, commonly using Given–When–Then. It is most useful when it helps technical and non-technical participants agree on a business rule. It should not be adopted only to reformat existing click-by-click scripts.

When should a manual test case be automated?

Consider automation when the behavior is stable, important, repeated often, and produces results that can be checked reliably. One-off, frequently changing, usability-focused, and exploratory tests may remain manual.

Can AI generate reliable test cases?

AI can produce useful drafts and suggest scenarios, but reliability depends on the quality of the source requirement and human review. It should assist test design rather than define undocumented product behavior.

About the author

Anastasiia Sokolinska

Chief Operating Officer

Anastasiia Sokolinska is the Chief Operating Officer at DeviQA, responsible for operational strategy, delivery performance, and scaling QA services for complex software products.