Test Case Template: Free Excel, Word & Google Sheets Downloads

A test case template is a reusable structure for documenting a test case, typically including a test case ID, title, description, preconditions, test steps, expected result, actual result and status. Using the same fields across your QA process makes individual tests easier to write, execute, review and reuse.

Below you'll find a ready-to-copy software test case template, a filled example and specialized templates for functional, login, API, acceptance, integration, performance, security, mobile, regression and exploratory testing.

You can also download editable versions without creating an account.

FREE TEST CASE TEMPLATES

• Excel (.xlsx): Standard, Agile and Detailed sheets plus a Reference sheet that explains each field
• Word (.docx): editable document tables
• Google Sheets-ready CSV: import directly into Google Sheets

No sign-up. No form. Fully editable.

If you're looking for documentation for an entire testing project rather than an individual test, use our test plan template instead.

What is a test case template?

A test case template is a standardized format for recording what should be tested, the conditions required before testing, the actions a tester should perform and the outcome that determines whether the test passed.

A template doesn't tell you what to test. It gives every test the same structure.

For example, “test checkout” is too broad to be a useful test case. A structured case might specify:

• which checkout behavior is being validated
• which account or product state is required
• the exact actions to perform
• what should happen after each critical action
• the result observed during execution
• whether the case passed or failed

That distinction also separates a detailed test case from a broader test scenario. If you're unsure which one you need, see our guide to test cases vs test scenarios.

A good template should also be simple enough that completing it doesn't become a documentation project of its own. For most manual QA work, 8 core fields are enough to describe an executable test. Larger teams can then add optional fields such as priority, requirement ID, environment, test data, owner or automation status.

8 essential fields in a test case template

A basic test case can be useful without dozens of columns. Start with these eight fields.

1. Test Case ID

A unique identifier such as TC001 or AUTH-014.

IDs make cases easier to reference in bug reports, test suites, release notes and conversations between QA and development.

2. Title

A short description of the behavior being tested.

Use an outcome-focused title such as Verify item addition to cart rather than a vague label such as Cart test.

3. Description

A brief explanation of the purpose or scope of the test.

This field is particularly useful when the title alone doesn't explain the business rule or edge case being validated.

4. Preconditions

The state that must exist before the tester starts.

For example: the user is logged in, the product is in stock and the shopping cart is empty.

5. Test steps

The actions required to execute the case.

Keep them specific enough that another tester can reproduce the same flow without asking what you meant.

6. Expected result

The correct outcome if the feature works as intended.

Whenever possible, describe an observable result rather than writing “works correctly.”

7. Actual result

What actually happened when the test was executed.

This is different from status. For example, the actual result may be Product appears in cart with quantity 1 and total €49, while status records Passed.

8. Status

The execution outcome, commonly Passed, Failed, Blocked or Not run.

Status records whether the observed result met the expected result.

For automated tests, some of these concepts are represented directly inside the test itself. Our guide to writing automation test cases shows how manual test logic translates into executable automation.

Standard test case template

This is the version I'd use for most manual functional QA.

You can copy the table directly into a spreadsheet, test management tool or document.

This version has 11 fields. The first eight are the core structure; test data, priority and requirement ID add useful traceability without making the template difficult to maintain.

Filled test case example

Here's the same structure as a completed case.

TC001: Verify item addition to cart

Description: Confirm that a customer can add an in-stock product to the shopping cart.

Preconditions:

• the product is available
• the user is on the product details page
• the cart contains no items

Steps:

1. Confirm the product shows as available.
2. Click Add to cart.
3. Open the shopping cart.

Expected result: The selected product appears in the cart with quantity 1, the correct unit price and the correct subtotal.

Actual result: The product appears in the cart with quantity 1 and the displayed price matches the product page.

Status: Passed.

A single case should normally validate one clear behavior. If you want to test quantity changes, removing a product, an out-of-stock item and cart persistence, create separate test cases rather than turning TC001 into a 20-step workflow.

For more examples of this type, see our library of ecommerce website test cases.

Agile test case template

Agile teams often need less documentation than a regulated or heavily process-driven QA team.

A useful Agile test case still records enough information to reproduce a result but keeps traceability close to the user story.

You can add automation status when the team uses manual and automated tests together.

Agile doesn't make structured test cases obsolete. It simply means documentation should support delivery rather than exist for its own sake.

If multiple related test cases need to run together, organize them into a test suite instead of expanding one case indefinitely.

Document-style test case template

Some teams need a test case that reads more like a controlled QA document than a spreadsheet row.

This structure works well when approvals, traceability or detailed evidence matter.

Use this format only when the extra documentation serves a purpose. For a small SaaS team, an 11-field controlled document may create more work than value.

Functional test case template

A functional test case checks that a feature behaves according to its requirements.

A useful structure is:

ID → feature → requirement → preconditions → input → steps → expected result → actual result → status

Example:

FUNC-014: Apply a valid discount code

Preconditions: cart contains one eligible product.

Steps:

1. Open cart.
2. Enter a valid discount code.
3. Click Apply.

Expected result: the discount is applied once and the order total is recalculated correctly.

Functional cases are often strong candidates for regression coverage once the feature becomes stable.

Login test case template

Authentication benefits from separate positive, negative, security and usability cases.

Example:

LOGIN-001: Successful login with valid credentials

Preconditions: Registered active user exists.

Test data: Valid email and password.

Steps:

1. Open the login page.
2. Enter a valid email.
3. Enter the correct password.
4. Click Log in.

Expected result: User reaches the authenticated area and a valid session is created.

Don't place successful login, incorrect password, empty fields, lockout behavior and password reset into the same case. Treat them as separate behaviors.

For a much larger set of examples, use our guide to test cases for a login page.

API test case template

API cases need to describe the request and response explicitly.

Useful additional fields include:

• endpoint
• HTTP method
• headers
• request body
• authentication
• expected status code
• expected response
• response-time requirement

Example:

API-012: Create order with valid payload

Request: POST /orders

Expected status: 201

Expected result: a new order is created and the response includes a valid order ID matching the submitted customer and product data.

Avoid using the browser-oriented template unchanged for API testing. “Click button” and “page displays” don't describe an API contract.

Acceptance test case template

Acceptance tests answer a business-facing question:

Does the implemented behavior satisfy the acceptance criterion?

Example:

ACC-004: Returning customer can complete checkout using a saved address

Acceptance criterion: authenticated users can select a previously saved shipping address without re-entering it.

The expected result should reflect the agreed requirement rather than implementation details.

This makes acceptance cases useful for product owners, stakeholders and UAT, not only QA engineers.

Integration test case template

Integration cases validate how two or more components interact.

Add fields such as:

• systems/components involved
• trigger
• input
• expected data exchange
• expected downstream state

Example:

INT-009: Successful order creates payment record

Precondition: checkout service and payment sandbox are available.

Action: submit a valid order.

Expected result: checkout receives a successful payment response and stores the correct payment ID against the order.

For complex flows, record which boundary failed rather than only marking the complete case as failed.

Performance test case template

Performance cases need measurable acceptance criteria.

“Page should load fast” isn't enough.

Record:

• workload
• concurrent users
• duration
• environment
• metric
• threshold
• observed result
• status

Example:

PERF-006: Login endpoint under expected peak traffic

Load: 100 concurrent virtual users.

Duration: 10 minutes.

Expected result: define the agreed response-time and error-rate thresholds for the project before execution.

The threshold should come from your own performance requirements rather than from an arbitrary universal benchmark.

Security test case template

Security cases should clearly describe the threat or control being tested.

Example:

SEC-011: Reject unauthorized access to account settings

Precondition: user is not authenticated.

Steps:

1. Request the account settings URL directly.
2. Observe the response.

Expected result: the application doesn't expose protected account data and redirects or returns the appropriate unauthorized response.

Security cases may also include authentication, authorization, session handling, input validation and sensitive-data exposure.

Don't treat a basic security checklist as a replacement for a professional security assessment when the risk requires one.

Mobile test case template

Mobile cases often need environment fields that aren't necessary for desktop web testing.

Add:

• device
• operating system/version
• screen size
• orientation
• network condition
• app version

Example:

MOB-018: Checkout survives orientation change

Device: defined test device.

Precondition: customer has entered delivery information.

Action: rotate the device before continuing checkout.

Expected result: previously entered data remains available and the user can continue the workflow.

If the product is responsive web rather than a native mobile app, browser and viewport may be more useful fields than device model.

Regression test case template

Regression cases protect behavior that already works and should remain stable after changes.

Useful additional fields include:

• related defect or requirement
• regression area
• automation status
• last execution
• risk/priority

Example:

REG-031: Discount remains applied after cart quantity change

This case might be created after a previous defect where changing quantity removed the discount unexpectedly.

Regression suites should prioritize stable, repeatable cases around critical functionality. Our guide to regression testing explains how those cases fit into a wider regression strategy.

If the suite becomes repetitive, consider automating regression testing instead of manually executing the same spreadsheet every release.

Exploratory test case template

Strictly speaking, exploratory testing doesn't require predetermined test cases in the same way scripted testing does.

A lightweight session template is usually more useful.

Record:

• session ID
• charter
• area under test
• test data
• time box
• observations
• defects
• questions
• follow-up tests

Example charter:

Explore cart behavior when products become unavailable between product selection and checkout.

The goal isn't to predict every action before testing begins. It's to give the exploratory session enough direction and capture what the tester learns.

Which test case template should you use?

You don't need a different spreadsheet for every testing method.

The standard template is enough for most teams. Add specialized fields only when they change how the test is executed or interpreted.

Keep the format as small as possible while still making the result reproducible.

How to write a good test case

A template helps with consistency, but it can't turn a vague test into a useful one.

Keep one main objective per test case

“Verify checkout” isn't specific enough.

“Verify a customer can complete checkout using a valid Visa test card” gives the tester a clear target.

Atomic cases are easier to understand, reuse and automate. Read our guide to atomic test cases if your current cases contain long chains of unrelated checks.

Make preconditions explicit

If an account must exist, say so.

If the cart must contain a product, specify it.

A case that works only because its author knows the hidden setup isn't reusable documentation.

Use numbered actions

Three precise steps are usually easier to execute than one paragraph.

Each action should describe what the tester does, while the expected result should describe what the product does in response.

Make expected results observable

Avoid:

The feature works correctly.

Prefer:

The product appears in the cart with quantity 1 and the subtotal equals the displayed unit price.

The second version gives you something you can actually verify.

Keep actual result and status separate

The actual result records what happened.

The status classifies that result.

For example:

Actual result: POST /orders returned 500 and no order was created.

Status: Failed.

A failed case usually becomes a defect report, which then follows its own workflow. Our guide to the bug life cycle explains each status from New to Closed.

Update important cases when the product changes

A stale test case can be worse than no documentation because it creates false confidence.

Review high-risk regression cases whenever the related feature or requirement changes.

Can AI generate test cases?

Yes. Generative AI can turn requirements, user stories or feature descriptions into draft test cases.

The useful part is speed: instead of starting with an empty spreadsheet, you can ask an AI tool for positive, negative, boundary and edge cases in a consistent structure.

The risk is treating generated cases as authoritative.

AI doesn't automatically know:

• undocumented business rules
• production incidents
• historical defects
• your real architecture
• the most important risks
• test data constraints
• what shouldn't be tested at UI level

Use generated cases as a first draft, then review them like any other QA artifact.

AI prompt for generating test cases

You can copy this prompt and replace the bracketed information.

You are a senior QA engineer. Create test cases for the following feature:

Feature: [describe feature]

Requirements / acceptance criteria:
[paste requirements]

Create a table using these fields:
Test Case ID, Title, Description, Preconditions, Test Steps, Expected Result, Test Data, Priority.

Include positive, negative, boundary and error-handling cases.

Keep each test case atomic and executable independently.

Do not invent product behavior that isn't present in the requirements. If information is missing, list it as an open question instead.

After generating the cases, identify which ones are strong candidates for automation and explain why.

What to check manually after AI generates the test cases

Before importing generated cases into your QA workflow, verify:

1. every expected result against the real requirement
2. invented assumptions or business rules
3. duplicated cases
4. missing high-risk paths
5. realistic test data and preconditions
6. whether the test belongs at UI, API, integration or unit level
7. whether sensitive or destructive scenarios require a controlled environment

AI can reduce writing time. It doesn't replace risk analysis or product knowledge.

For teams already investigating AI-assisted QA, our guide to AI testing tools covers a broader set of use cases beyond writing test documentation.

Download the free test case templates

Use whichever format fits your workflow. All three files use the same 13 columns: the 11 fields from the standard template above plus Owner and Automation Status.

Excel test case template

Download the Excel template

Best for teams that want filters, status tracking, bulk editing and easy reuse across releases.

File contents:

• Standard, Agile and Detailed sheets with filled examples
• a Reference sheet explaining each field
• status and priority fields

The Agile and Detailed sheets keep the same 13 columns and each shows an example written in that style. To use the Agile or document-style fields shown earlier, such as User Story or Reviewer, add them as extra columns.

Word test case template

Download the Word template

Best for teams that need a document-style case, approvals or a format that can sit alongside other QA documentation.

Google Sheets test case template

Download the Google Sheets-ready CSV

Best for shared QA work where several people need to edit the same cases.

No sign-up is required to download any of these templates.

Test case template vs test plan template

These documents solve different problems.

A test case template describes an individual test: setup, steps and expected result.

A test plan describes the broader testing effort: scope, objectives, resources, environments, schedule, risks and execution strategy.

Don't try to turn a test case spreadsheet into a complete project plan.

If you need the broader document, use our test plan template.

Likewise, if you're building cases specifically for an online store, our ecommerce test cases provide concrete checkout, search, cart and payment scenarios rather than another generic template.

Frequently asked questions about test case templates

What is a test case template?

A test case template is a reusable structure for documenting a software test. A basic template records the case ID, title, description, preconditions, test steps, expected result, actual result and execution status so testers can create and run cases consistently.

What should be included in a software test case template?

Start with 8 core fields: ID, title, description, preconditions, steps, expected result, actual result and status. Larger QA workflows may also add test data, priority, requirement ID, environment, owner, evidence and automation status.

Can ChatGPT generate test cases?

Yes. ChatGPT and other generative AI tools can create draft test cases from feature descriptions, user stories and acceptance criteria. Review generated cases for invented requirements, missing risks, duplicate coverage and incorrect expected results before using them in a real QA process.

Which AI is best for QA testing?

There isn't one AI tool that's best for every QA task. General-purpose models can help draft test cases, summarize requirements and explore edge cases, while specialized testing tools can support test generation, maintenance or execution. Choose based on the problem you're trying to solve rather than the “AI” label.

How can I automatically generate test cases?

Start with structured requirements or acceptance criteria, then use an AI tool or testing platform to generate cases in a fixed schema. Ask for positive, negative, boundary and error-handling coverage. Human review should follow before cases are accepted, automated or added to a regression suite.

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

A test scenario is a high-level statement of what should be tested, such as Test the checkout process. A test case describes exactly how one behavior will be tested, including preconditions, steps and expected results. See our full test case vs test scenario comparison for examples.