How to Write Test Cases with Examples

What is a Test Case?

A test case is a set of actions, inputs, and expected outcomes that helps testers verify whether a specific feature or functionality in software works as intended. It serves as a step-by-step guide that defines what to test, how to test it, and what result to expect.

Think of a test case as a recipe for validation — it tells you the exact ingredients (test data), the process (steps to perform), and what a perfect dish (expected result) should look like.

A well-written test case helps ensure:

• The software meets the business and user requirements.
• Bugs or unexpected behaviors are caught early.
• Testing can be repeated and reviewed by any QA professional.
• Teams can trace which requirement each test is verifying.

👉 Enroll for Free Live Software Testing Project

Steps to Create Test Cases in Manual Testing

Let’s create a Test Case for the scenario: Check Login Functionality

Step 1) A simple test case to explain the scenario would be

Test Case #	Test Case Description
1	Check response when valid email and password is entered

Step 2) Test the Data.
In order to execute the test case, you would need Test Data. Adding it below

Test Case #	Test Case Description	Test Data
1	Check response when valid email and password is entered	Email: guru99@email.com Password: lNf9^Oti7^2h

Identifying test data can be time-consuming and may sometimes require creating test data afresh. The reason it needs to be documented.

Step 3) Perform actions.
In order to execute a test case, a tester needs to perform a specific set of actions on the AUT. This is documented as below:

Test Case #	Test Case Description	Test Steps	Test Data
1	Check response when valid email and password is entered	1) Enter Email Address 2) Enter Password 3) Click Sign in	Email: guru99@email.com Password: lNf9^Oti7^2h

Many times, the Test Steps are not as simple as above, hence they need documentation. Also, the author of the test case may leave the organization or go on a vacation or be sick and off duty, or be very busy with other critical tasks. A recently hired may be asked to execute the test case. Documented steps will help him and also facilitate reviews by other stakeholders.

Step 4) Check the behavior of the AUT.
The goal of test cases in software testing is to check the behavior of the AUT for an expected result. This needs to be documented as below

Test Case #	Test Case Description	Test Data	Expected Result
1	Check response when valid email and password is entered	Email: guru99@email.com Password: lNf9^Oti7^2h	Login should be successful

During test execution time, the tester will check expected results against actual results and assign a pass or fail status

Test Case #	Test Case Description	Test Data	Expected Result	Actual Result	Pass/Fail
1	Check response when valid email and password is entered	Email: guru99@email.com Password: lNf9^Oti7^2h	Login should be successful	Login was successful	Pass

Step 5) That apart your test case -may have a field like,
a precondition that specifies things that must be in place before the test can run. For our test case, a precondition would be to have a browser installed to have access to the site under test. A test case may also include postconditions that specify anything that applies after the test case completes. For our test case, a postcondition would be time & date of login are stored in the database

Key Elements of a Test Case

A standard test case typically includes:

1. Test Case ID – Unique identifier (e.g., TC001)
2. Title or Description – What the test verifies
3. Preconditions – What must exist before the test starts
4. Test Steps – The exact actions to perform
5. Test Data – Input values or parameters
6. Expected Result – The outcome you should see
7. Actual Result – What actually happened
8. Status – Pass, Fail, or Blocked

Test Case vs Test Scenario

A test scenario describes what needs to be tested — the broad functionality or user journey.

A test case, on the other hand, explains how that functionality will be verified — the exact steps, data, and expected results.

In simple terms:

• Test Scenario = Idea of what to test.
• Test Case = Implementation of how to test that idea.

Think of it like this —

“If a test scenario is a chapter title, each test case is a paragraph that explains that chapter in detail.”

Example Illustration:

Let’s take an example to make it clearer:

Test Scenario:

“Check the login functionality of the website.”

Related Test Cases:

1. Verify login with valid username and password.
2. Verify error message with invalid password.
3. Verify login with empty fields.
4. Verify password field hides input text.

Here, the scenario is a single functional objective, while test cases break it into specific, testable conditions.

Read for more information about Difference Between Test Case vs Test Scenario

Benefits of Writing High-Quality Test Cases

• High-quality test cases ensure thorough test coverage, consistency, and traceability across the entire QA process.
• They help testers catch bugs early, maintain regression stability, and guarantee that every functionality aligns with business requirements.
• Well-written test cases are clear, reusable, and repeatable, allowing any tester or automation tool to execute them reliably.
• They also act as a communication bridge between developers, testers, and stakeholders — reducing ambiguity and saving time.
• By documenting test objectives, steps, and results, teams can measure progress, comply with standards, and manage updates efficiently.
• Most importantly, good test cases reduce maintenance costs, speed up automation, and provide confidence in software quality.
• They serve as living documentation for onboarding new testers and as structured input for AI and test management tools.

Common Mistakes to Avoid When Writing Test Cases

Even experienced testers make small errors that weaken test quality.

Avoiding these mistakes can dramatically improve the accuracy, clarity, and maintainability of your test suite.

1. Writing vague steps: Ambiguous instructions like “check login page” confuse testers. Use clear, action-based steps.
2. Skipping negative scenarios: Always include invalid inputs or boundary tests to ensure full coverage.
3. Reusing unclear test data: Unlabeled or inconsistent data makes test results unreliable. Maintain a shared test data sheet.
4. Overcomplicating test cases: Long, multi-step cases are hard to maintain. Keep each case focused and atomic.
5. Ignoring updates after product changes: Outdated test cases create false results. Review and revise regularly.
6. Missing traceability: Always link test cases to requirements to track coverage and compliance.
7. Skipping peer reviews: Fresh eyes catch unclear or redundant steps early.

FAQs