How to Write Test Cases in Software Testing: Step-by-Step Guide + Examples

Writing a test case is not about filling rows in an Excel sheet. A good test case turns a requirement into a clear, repeatable check that another tester can execute and reach the same pass/fail conclusion.
If you are learning how to write test cases in software testing, start with one rule:

Understanding how to write test cases correctly helps you create tests that are clear, repeatable, and easier to review.
Make it clear what you are testing, what conditions must exist, what action is performed, and what result proves that the feature works correctly.

In this test case writing guide, you will learn how to turn requirements into test scenarios, write complete test cases, cover positive and negative conditions, choose the right format, and use AI without trusting it blindly.

How to Write Test Cases: Quick Answer

To write an effective test case:

1. Understand the requirement and acceptance criteria.
2. Identify the behavior or risk you need to test.
3. Create a clear test case ID and title.
4. Define any required preconditions.
5. Specify the exact test data.
6. Write clear test steps in logical order.
7. Define an observable expected result.
8. Assign priority based on risk.
9. Link the test case to its requirement.
10. Review it before execution.

A tester who was not involved in writing the test should still be able to understand what is being checked and determine whether it passed or failed.

What Is a Test Case?

A test case is a documented set of conditions, inputs and expected results created to verify a specific behavior of a software product.
ISO/IEC/IEEE 29119-1:2022 defines a test case in terms of preconditions, inputs and expected results used to drive testing toward a particular test objective.
For example, this is too vague:
Test the login page.
This is testable: Verify that a registered user can log in using a valid email address and password.
The second version tells the tester exactly which behavior needs to be verified.
Good test cases improve consistency, traceability and communication between testers, developers and product teams.

The wider cost of software quality problems is significant. CISQ estimated the cost of poor software quality in the United States at at least $2.41 trillion in 2022.

Test cases alone cannot prevent all software failures, but they provide teams with a repeatable way to verify requirements and reduce avoidable gaps.

Test Case vs Test Scenario vs Test Procedure

These terms are related, but they are not identical.

Term	Meaning	Example
Test scenario	A situation or behavior that needs to be investigated	Verify user login
Test case	A specific set of conditions, inputs and expected results	Login with valid registered credentials
Test data	Values used while executing the test	user@example.com / ValidPass123!
Test procedure	The sequence used to execute one or more test cases, including setup where required	Prepare account → execute login cases → clean up
Test suite	A collection of related test cases	Login and authentication regression suite

A single test scenario can produce multiple test cases.

For example:

Scenario: Test login functionality

Possible test cases:

• Login with valid credentials
• Login with an incorrect password
• Login with an unregistered email
• Submit with the email field empty
• Submit with the password field empty
• Test account states such as locked or disabled, if those behaviors exist in the requirements

The important phrase is “if those behaviors exist in the requirements.”

Do not invent an expected result simply because it sounds logical. If the specification does not explain what should happen, clarify it with the relevant product owner, developer or stakeholder.

What Should a Test Case Include?

There is no rule saying every project needs fifteen fields in every test case.

The correct amount of detail depends on the product, risk, team and testing context.

Minimum useful test case

For a simple internal project, you may only need:

Field	Purpose
Test Case ID	Gives the case a unique reference
Title	States exactly what is being verified
Preconditions	Defines required starting conditions
Test Data	Specifies the input values
Steps	Explains what to do
Expected Result	Defines what must happen for the test to pass

More complete test case format

Larger teams or critical systems may also include:

Field	Example
Requirement ID	AUTH-01
Test Case ID	TC-LOGIN-001
Module	Authentication
Priority	High
Environment	Staging / Chrome
Preconditions	Active registered account exists
Test Data	Valid registered email and password
Steps	Ordered actions
Expected Result	Observable correct behavior
Actual Result	Behavior seen during execution
Status	Pass / Fail / Blocked
Defect ID	BUG-214, when applicable

The goal is not maximum documentation.

The goal is enough documentation for reliable testing without creating unnecessary maintenance work.

Copy-Paste Test Case Template

You can use this simple test case template in Excel, Google Sheets, Jira or a dedicated test management tool.

Field	Value
Requirement ID
Test Case ID
Test Case Title
Module/Feature
Preconditions
Test Data
Test Steps
Expected Result
Actual Result
Priority
Status
Defect ID
Notes

If you are building your first QA portfolio, create a spreadsheet using this structure and practice with common flows such as login, signup, password reset, search and checkout.

How to Write Test Cases Step by Step

Step 1: Understand the Requirement

Do not start writing test cases before understanding what the feature is supposed to do.

Read the:

• User story
• Acceptance criteria
• Business rules
• UI design
• API specification
• Technical constraints
• Relevant existing behavior

Ask questions such as:

What is the user trying to achieve?

What should happen when everything is valid?

What should happen when something is invalid?

Are there limits, permissions or different user states?

What happens when a dependency fails? If the requirement is ambiguous, clarification is part of good testing.

Step 2: Identify Test Scenarios

Break the requirement into meaningful behaviors.

Suppose the requirement says:

A registered active user should be able to sign in with a valid email address and password.

The obvious scenario is successful login.

But you should also investigate relevant failure conditions:

• Incorrect password
• Unregistered email
• Missing required fields
• Disabled or locked account, if supported
• Session behavior
• Error handling
• Relevant browser/device conditions

At this stage, think about risk before quantity.

A payment failure or authentication defect normally deserves more attention than a low-impact cosmetic issue.

Step 3: Write a Specific Test Case Title

A title should tell another tester what is being verified without requiring them to open the test case.

Weak:

Test login

Better:

Verify login with valid credentials

Even better when context matters:

Verify an active registered user can log in with valid email and password

Use one test case for one clear objective whenever practical.

Step 4: Define Preconditions

Preconditions describe what must already be true before the test begins.

For example:

• User account exists
• Account is active
• User is logged out
• Test environment is available
• Required data has been created

Without preconditions, two testers can execute the same steps from different starting states and receive different results.

Step 5: Prepare Exact Test Data

Avoid vague instructions such as:

Enter a valid email.

Specify the value when reproducibility matters:

Email: user@example.com

Password: ValidPass123!

Real projects should use approved test accounts and non-sensitive test data rather than production credentials.

Step 6: Write Clear Test Steps

Each step should describe a meaningful action.

For example:

1. Open the login page.
2. Enter user@example.com in the email field.
3. Enter ValidPass123! in the password field.
4. Select Log In.

Avoid adding unnecessary click-by-click detail when the tester already understands the product.

A senior tester running an internal regression suite may need much less instruction than an external UAT participant using the product for the first time.

Step 7: Write an Observable Expected Result

This is one of the most important parts of test case writing.

Weak:

Login should work.

Better:

The user is authenticated and redirected to the dashboard.

Stronger when the requirement supports it:

The dashboard opens and displays the authenticated user’s account information without showing an authentication error.

Expected results should describe something that can actually be observed.

Avoid phrases such as:

• Works fine
• Looks good
• Behaves properly
• Works as expected

Those phrases do not define what “correct” means.

Step 8: Assign Priority Using Risk

Not every test case has equal importance.

Consider: Business impact × probability of failure × frequency of use

Authentication, payments, permissions and data-loss scenarios often deserve higher attention than rarely used, low-impact functions. Priority should help the team decide what must run first when testing time is limited.

Step 9: Link the Test Case to the Requirement

Traceability answers a basic question:

Which requirement does this test case verify?

A simple Requirement Traceability Matrix can help.

Requirement	Test Cases	Status
AUTH-01: Active user can log in	TC-LOGIN-001	Passed
AUTH-02: Invalid credentials are rejected	TC-LOGIN-002, TC-LOGIN-003	Not Run
AUTH-03: Required fields are validated	TC-LOGIN-004, TC-LOGIN-005	Passed

This makes it easier to spot requirements that have no corresponding test coverage.

Step 10: Review Before Execution

Before marking a test case ready, ask:

Can another tester understand it without asking me what I meant?

Are the test data and starting conditions clear?

Is the expected result objectively verifiable?

Does this test actually trace back to a requirement or meaningful risk?

A peer review can catch unclear assumptions before they become execution problems.

A Complete Test Case Example

Consider this fictional requirement:
AUTH-01: An active registered user can log in using a valid email and password and is then taken to the dashboard.
A complete test case might look like this:

Field	Example
Requirement ID	AUTH-01
Test Case ID	TC-LOGIN-001
Title	Verify login with valid credentials
Module	Authentication
Priority	High
Preconditions	Active registered account exists and user is logged out
Test Data	user@example.com / ValidPass123!
Step 1	Open the login page
Step 2	Enter the registered email
Step 3	Enter the valid password
Step 4	Select Log In
Expected Result	User is authenticated and redirected to the dashboard
Actual Result	To be completed during execution
Status	Not Run

Notice that the expected result comes directly from the fictional requirement. If the requirement never said the dashboard must load within three seconds, we should not add “within three seconds” to the expected result unless that performance requirement exists somewhere else. That is a common mistake in AI-generated and human-written test cases: inventing reasonable-sounding behavior instead of testing documented behavior.

Bad Test Case vs Good Test Case

Bad example

Title: Test login
Steps: Try logging in.
Expected: It should work.
This gives the tester almost nothing useful.

Better example

Title: Verify an active registered user can log in with valid credentials
Precondition: Active registered account exists.
Test Data: user@example.com / ValidPass123!
Steps:

1. Open the login page.
2. Enter the valid registered email.
3. Enter the correct password.
4. Select Log In.

Expected Result: User is authenticated and redirected to the dashboard.
The second version is repeatable, reviewable and much easier to troubleshoot if it fails.

Use the 3C Test Before Approving a Test Case

A simple way to review a test case is the 3C rule:

1. Clear

Can another tester understand exactly what is being verified?

2. Controlled

Are the starting state, environment and required test data defined well enough to reproduce the test?

3. Checkable

Does the expected result give the tester an objective way to decide Pass or Fail?

If a test case fails one of these three checks, improve it before adding it to a regression suite.

Positive, Negative and Boundary Test Cases

Strong coverage usually requires more than a happy path.

Positive test case

Checks valid input under expected conditions.
Example:
Enter a valid registered email and correct password → login succeeds.

Negative test case

Checks invalid data or error behavior.
Example:
Enter a valid email and incorrect password → authentication is rejected according to the specified error behavior.

Boundary test case

Checks values around a defined limit.
If a username requirement allows 3 to 20 characters, useful boundaries include:

• 2 characters
• 3 characters
• 20 characters
• 21 characters

Do not invent limits that do not exist in the requirements.

Test Design Techniques That Improve Your Test Cases

Writing more test cases does not automatically mean better coverage.
Test design techniques help you choose meaningful cases.

Equivalence Partitioning

Group inputs expected to behave similarly and select representative values from each group.
Instead of testing every possible age between 18 and 60, for example, you may identify valid and invalid input classes based on the actual business rules.

Boundary Value Analysis

Test values at and immediately around important limits.
This is especially useful for:

• Minimum/maximum lengths
• Quantity limits
• Date ranges
• Numeric ranges

File-size restrictions

Decision Tables

Use decision tables when outcomes depend on combinations of business rules.
They are useful for situations such as:

• Discounts
• User permissions
• Loan rules
• Shipping logic
• Subscription eligibility

State Transition Testing

Use this when system behavior depends on its previous state.
Examples include:

• Active → locked account
• Draft → submitted → approved

Unauthenticated → authenticated → session expired

Pairwise/Combinatorial Testing

When a feature has many interacting parameters, pairwise or other combinatorial techniques can reduce the number of combinations you execute while still systematically covering interactions.
Use the technique because it matches the testing problem—not simply because you want fewer cases.

How Many Test Cases Should You Write?

There is no correct universal number.
One requirement might need two test cases. Another may need dozens.
Instead of asking:
“How many test cases should I write?”
ask:
“Which risks, rules and user behaviors still have no meaningful coverage?”
Consider:

• Business criticality
• Number of business rules
• Valid and invalid input groups
• Boundary conditions
• User roles
• Dependencies
• Previous defects
• Complexity
• Frequency of use
• Consequences of failure

When learning how to write test cases, focus on meaningful coverage instead of trying to reach a fixed number of cases. A hundred repetitive test cases can provide less value than twenty carefully designed ones.

Writing Test Cases in Excel or Google Sheets

Spreadsheets work well for learning, personal projects and smaller test suites.
Useful columns include:
Test Case ID | Title | Preconditions | Test Data | Steps | Expected Result | Actual Result | Priority | Status
Use filters and dropdowns for fields such as:
Priority: High / Medium / Low
Status: Not Run / Pass / Fail / Blocked
Once the suite becomes difficult to maintain, trace or report on manually, a dedicated test management system may be more practical.

Writing Test Cases in Jira

Teams that already use Jira commonly connect testing workflows through test-management applications such as Xray or Zephyr.

These tools add capabilities such as test-case organization, executions, traceability and reporting within the Jira ecosystem. Atlassian publishes an official tutorial for managing test cases through Xray, while Zephyr is also available through the Atlassian Marketplace.
A typical workflow might look like:
User Story → Requirement → Test Cases → Test Execution → Defect → Retest
The important part is traceability—not which tool logo appears on the screen.
If you are still deciding which QA tools to learn, see our guide to software testing tools for QA engineers.

Writing API Test Cases

API test cases follow the same basic thinking as UI cases, but the inputs and observations are different.
Instead of clicking buttons, you may send an HTTP request.
Instead of checking a page, you inspect the response.
Example:

Field	Example
Endpoint	POST /api/v1/login
Method	POST
Test Data	Valid registered credentials
Expected Status	200, if specified by the API contract
Expected Body	Required response fields match the API contract
Additional Checks	Headers, schema, authorization and error behavior

Negative API cases may include:

• Missing required fields
• Invalid field types
• Invalid authentication
• Expired tokens
• Unauthorized roles
• Malformed request bodies
• Values outside allowed limits

Security expectations should come from approved requirements and security standards rather than assumptions.

From Manual Test Case to Automated Test

Not every manual test case should automatically become an automated test.
Good automation candidates are usually stable, repeatable and executed frequently.
A simplified Python-style example might look like:

def test_login_with_valid_credentials():
    result = login(
        email=”user@example.com”,
        password=”ValidPass123!”
    )

    assert result.success is True
    assert result.redirect_url == “/dashboard”

The concepts map naturally:
Preconditions → setup/fixtures
Test actions → function or UI/API calls
Expected results → assertions
But automated tests require additional engineering decisions such as environment setup, data management, isolation and cleanup.

How to Write Test Cases Using AI

AI can speed up test design, but it should be treated as an assistant—not as the source of truth.
A practical workflow is:

1. Give the AI the actual requirement and acceptance criteria.
2. Ask for positive, negative and boundary scenarios.
3. Request the output in your team’s test case format.
4. Review every expected result against the real specification.
5. Remove duplicates and irrelevant cases.
6. Add product-specific risks the AI missed.
7. Replace invented test data or assumptions.
8. Approve the cases only after human review.

What AI is useful for

AI can help with:

• Generating first-pass scenarios
• Brainstorming negative cases
• Identifying possible edge conditions
• Reformatting test cases
• Drafting automation skeletons
• Summarizing large requirements

Where AI commonly causes problems

AI may:

• Invent requirements
• Assume validation rules that were never specified
• Generate dozens of low-value variations
• Produce incorrect expected results
• Miss company-specific business logic
• Create tests that look professional but do not test meaningful risk

This matters because AI adoption in quality engineering is moving rapidly. The World Quality Report 2025–26 reported that 89% of surveyed organizations were piloting or deploying GenAI-augmented quality-engineering workflows, while only 15% had scaled it enterprise-wide.

The gap between experimentation and enterprise-scale adoption is a useful reminder: generating something quickly is not the same as trusting it without review.
GitHub has also reported a controlled experiment in which developers using Copilot completed a specific coding task 55% faster than the control group. That result relates to coding productivity rather than test-case accuracy, so it should not be interpreted as proof that AI-generated test cases are automatically better.

Common Test Case Writing Mistakes

Writing vague titles

Avoid:
Check registration
Prefer:
Verify registration succeeds with all required valid fields

Using subjective expected results

Avoid:
Page looks correct.
Specify which visible behavior or requirement determines success.

Testing multiple unrelated objectives in one case

A failure becomes harder to diagnose when one test case attempts to validate many separate behaviors.

Writing only positive tests

Real users make mistakes, APIs fail and systems receive invalid data.
Include relevant negative and boundary conditions.

Adding requirements that do not exist

This is especially common when test cases are generated by AI.
If expected behavior is unclear, raise the ambiguity instead of silently inventing an answer.

Over-documenting simple tests

Not every internal test requires ten lines of instructions.
Match the detail to the risk and the person executing the test.

Keeping obsolete test cases forever

Products change.
Review regression suites periodically and update or remove tests for features and rules that no longer exist.

Test Case Review Checklist

Before approving a test case, verify that:

• The title describes one clear purpose.
• The test traces back to a requirement, risk or defined objective.
• Preconditions are sufficient.
• Test data is clear.
• Steps are understandable and logically ordered.
• The expected result is objective.
• No business rule has been invented.
• Important negative and boundary conditions were considered.
• Priority reflects actual risk.
• Another tester could execute the test without depending on the author.
• The test is maintainable enough to remain useful after future releases.

Which Test Case Format Should You Use?

There is no single best format for every team.

Approach	Best suited for	Main advantage
Excel / Google Sheets	Learning and smaller projects	Simple and inexpensive
Jira + Xray/Zephyr	Teams already working heavily in Jira	Requirements and testing stay connected
Dedicated test management tools	Larger or frequently executed suites	Reporting, organization and traceability
Code-based automated tests	Stable repeatable checks	Fast repeat execution and CI/CD integration

Use the simplest system that still gives your team the traceability, repeatability and reporting it actually needs.

Frequently Asked Questions

What is the easiest way to write a test case?

Start with five questions: What am I testing? What must be true first? What data will I use? What action will I perform? What exact result means the test passed?
Convert those answers into a title, preconditions, test data, steps and expected result.

What is a test case example?

A simple example is:
Title: Verify login with valid credentials
Precondition: Active registered account exists
Steps: Open login page → enter valid email → enter correct password → select Log In
Expected Result: User is authenticated and redirected according to the login requirement.

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

A test scenario describes a broader situation that should be tested, while a test case defines a specific set of conditions, inputs and expected results used to test part of that scenario.
One scenario can therefore generate several test cases.

How many test cases should be written for one requirement?

There is no fixed number.
The number depends on business rules, risk, input combinations, boundaries, user roles and possible failure conditions. Focus on meaningful coverage instead of targeting a specific count.

What makes a good test case?

A good test case is clear, repeatable, traceable and objectively verifiable. It defines enough context and test data for another tester to execute it without guessing.

Can AI write test cases accurately?

AI can generate useful first drafts and suggest overlooked scenarios, but its output must be reviewed against the real requirement. AI can invent expected behavior or business rules that sound plausible but are not actually part of the product.

Should I write test cases in Excel or Jira?

Excel or Google Sheets is sufficient for learning and many small projects. Teams that need stronger traceability, reporting and test execution management often use Jira integrations or dedicated test management tools.

Final Thoughts

Learning how to write test cases is less about memorizing a template and more about turning requirements into clear, meaningful checks.
Start with the requirement.
Understand the user’s goal and the risks.
Separate scenarios into specific test cases.
Use real test data.
Define observable expected results.
Cover the important negative and boundary conditions.
And never invent an expected behavior just to complete a test case.

If another tester can execute your test without asking what you meant—and both of you can agree objectively whether it passed—you have probably written a useful test case.
If you are building your QA career from the beginning, read our software testing career guide for a complete learning roadmap.
As your QA skills grow, the next step is learning how to organize these cases in test management tools, connect them with requirements and defects, and decide which stable regression checks are worth automating.

Sources

ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — General concepts.
Consortium for Information & Software Quality — Cost of Poor Software Quality in the U.S.: A 2022 Report.
Capgemini, Sogeti and OpenText — World Quality Report 2025–26.
GitHub — Controlled research on Copilot and developer task completion speed.