Writing a good test case begins with understanding the requirement and then breaking it down into specific scenarios. Each test case should focus on a single objective, include clear steps, and define the expected result. Use consistent and clear language, and keep them updated as the product evolves.
In this guide, you'll learn what a test case is, how to write one effectively, and how to avoid common mistakes. We've also included examples and a free test case template to help you get started.
What is a test case in software testing?
A test case is a set of conditions and steps used to verify that a feature works as intended. It typically includes a title, test steps, expected results, and other key information to help ensure the test can be executed correctly and consistently. The core part of a test case contains step-by-step instructions for exactly how to test a feature. Think of it as a blueprint for verifying a feature functions as intended.
Test case vs related terminology
As an overview, test plans provide a high-level view of your testing strategy, test suites comprise a collection of tests, test scenarios represent the high-level features to be tested, and test cases represent a singular test.
Test plan vs test case
A test plan is the overarching strategy that defines the scope, objectives, resources, and schedule for a project. Test cases are the detailed steps for executing that plan. A software testing project might have a single plan with numerous test cases.
Test suite vs test case
A test case verifies a single piece of functionality. A test suite is a collection of test cases, often grouped by feature type or product area. Sometimes test suites are referred to as test scripts, but this is more common with automated testing.
Test scenario vs test case
A test scenario represents the high-level functionality or feature to be tested from the end-user's perspective. It's less detailed than a test case, whereas the test case breaks down exactly how to conduct a specific test within a scenario.
Benefits of writing test cases
Writing test cases can be a time-consuming process, especially in fast-paced teams, but the benefits are well worth the effort. Well-written test cases bring clarity to the testing process, improve team alignment, and ultimately lead to high-quality products.
Let's break down the benefits in detail:
Better test coverage
Taking the time to break down features into individual test cases means you're less likely to miss critical test paths, edge cases, or user flows. Test cases help you map tests directly to requirements or user stories, ensuring that every aspect of the product is accounted for, not just the obvious use cases.
Improved bug detection
With clearly defined test steps and expected results, it's much easier to identify when something isn't working as it should. Whether you're running manual tests or reviewing automated ones, a good test case pinpoints exactly what failed and where, speeding up the triage and debugging process.
Faster tester onboarding
New testers (or even non-testers jumping into testing duties) can hit the ground running when they have well-written test cases to follow. Instead of relying on tribal knowledge or vague documentation, they'll get step-by-step instructions and context that make it easier to learn the product and contribute immediately.
Ensures consistency in testing
When test cases are standardized and stored in a shared location, such as a test management tool, they promote consistent test execution across the entire testing team and all testing cycles. Regardless of who conducts the tests or when they're performed, the same process is followed, which helps ensure reliable and repeatable results. This ultimately increases confidence in the testing process, strengthening the entire team and product.
Who writes test cases?
Typically, QA engineers are responsible for writing and maintaining test cases. However, in agile environments, developers often write test cases alongside their code, especially for unit and integration testing.
Product managers or business analysts may also contribute to test cases, especially when aligning with acceptance criteria or business rules. There are no limits on who can write test cases. It comes down to having the right information, writing clearly, and capturing the necessary details that make a test case useful.
Now let's explore the elements of a test case. In other words, what fields do you include in a test case?
Test case format
Every test case should include a consistent set of components so anyone on your team can understand and use it. What information you include in your test cases is up to your business and testing needs.
We've broken down what we believe are the most important components of a test case, as well as some optional components to include.
Essential components
These are the most common and important things to capture for each test case.
- Test case ID: A unique identifier for traceability
- Title: A clear, concise name that describes what's being tested
- Description: A short explanation of the goal of the test
- Test steps: A step-by-step list of the specific actions to perform
- Expected results: What should happen if everything works correctly
- Pass/fail/skip status: The outcome of the test (filled out during test execution)
- Actual result: Notes from the test execution (filled out during test execution - more commonly, when a test fails)
Optional components
These are some optional fields you could include.
- Preconditions: What needs to be in place before the test starts
- Test data: Input or variables needed for the test
- Priority: Helps organize and focus effort
How to write good test cases
Writing test cases isn't rocket science, but it does require critical thinking, clear writing, and practice. Follow these steps to write test cases that are easy to understand, repeatable, and effective.
1. Understand the feature and requirements
Start by reviewing the user story, feature specification, or design to ensure you fully understand what needs to be tested. Without a complete understanding of the requirement, it's impossible to know how to test against it.
Tip: Collaborate with product managers and designers early to review requirements or designs that need clarification. The sooner you do this, the better, as the collaborative review process can lead to improvements before testing even begins.
2. Identify test scenarios
Break down the feature into specific behaviors or flows you want to test. Consider the distinct behaviors or conditions that the feature should handle. Each scenario represents a unique situation you'll want to verify with a test case or multiple test cases.
Tip: Ask yourself, "What are all the different ways someone could use this feature, both correctly and incorrectly?" Think of happy and unhappy paths.
3. Write clear steps
This is the most critical part of the test case, as it explains exactly how the tester should verify that a piece of functionality is working as expected. List out the actions a tester should take, one step per line, so it's easy to read quickly.
Tip: Use action verbs and consistent terminology to avoid confusion. Be super clear and avoid filler words.
4. Define expected results
Clearly describe what should happen after each step or at the end of the test. The tester compares their results with the expected results to determine the test's outcome, so it's crucial that this section is straightforward.
Tip: Ensure the expected result is specific and measurable, leaving no room for ambiguity or questions.
5. Review and refine
Test cases aren't "set it and forget it". Products evolve, features get introduced (or deprecated), causing a cascading effect on how existing functionality works. Software products undergo constant changes, which require test cases to be continuously updated.
Tip: Fix outdated test cases as soon as they are discovered, and consider scheduling a monthly or quarterly audit to ensure test cases stay current.
6. Organize in a test management tool
Products can have hundreds or thousands of test cases, which can get quite disorganized if you don't have an effective way to write and store them. Sure, you can fumble through spreadsheets and other files. Or, you can leverage a cloud-based test management tool that enables you to organize your testing documents, streamline your process, and improve collaboration.
Tip: Group related test cases into test suites to keep things organized.
Best practices for writing test cases
Whether you're an experienced test case writer or new, consider these best practices for writing test cases.
- Be clear and concise: Avoid unnecessary words and keep each part of the test case focused and to the point. Anyone on your team should be able to understand the test case at a glance.
- Use consistent language: Stick to consistent terminology across all test cases to prevent confusion. For example, avoid switching between "submit button" and "send" if they refer to the same action.
- Make them traceable to requirements: Link each test case to a user story or requirement. This helps identify gaps in testing and ensures solid coverage.
- Focus on a single objective per test case: Each test case should validate just one thing. Keeping your test cases focused makes them easier to read, faster to execute, and simpler to debug when issues arise.
- Keep them up to date: Test cases should evolve with the product. Make it a habit to review and revise them when features change or requirements shift.
Common mistakes in writing test cases
Even the most experienced testers can fall into bad habits when writing test cases. Here are some of the most common mistakes and how to avoid them.
Too vague
Vague instructions lead to inconsistent testing, missed bugs, and ultimately, annoyed customers. A test case like "Click the login button and verify it works" doesn't tell the tester what to input or what the expected result is. Sure, you can assume, but assumptions can also get you in trouble.
Example: "Click the button to log in" doesn't specify if or what to input before clicking the button. Whereas, "On the login page, click the 'Log In' button after entering valid credentials" tells the tester exactly what to do.
Skipping or unclear expected results
Without an expected result, or when expected results aren't clear, there's no way to know if the test passed or failed. Every test case needs to clearly state what should happen after each action or series of steps. Leave no room for questions.
Example: "The user should be redirected" doesn't specify where the tester should be redirected. A better version: "The user should be redirected to the welcome screen."
Overcomplicating steps
It's easy to try to pack too much into one test case or to write overly detailed steps that make the test case hard to follow. This slows down the testing process and increases the chance of mistakes.
Example: "Log in, navigate to settings, change password, then log out and back in" covers too much. Instead, split this into two test cases: one for changing the password, and one for verifying login with a new password.
Not updating test cases as the product changes
When the product changes but the test cases stay the same, you end up with outdated tests that confuse testers or flag false failures. This is especially common in fast-moving agile teams.
Example: If the "sign up" button was renamed "Create Account", your test case should be updated to reflect that change. Otherwise, it might mislead testers.
Neglecting edge cases
Focusing only on the happy path can leave critical gaps in your test coverage. Always think about what could go wrong, not just what could go right.
Example: A "reset password" test case might be easy to pass with a valid email address, but what happens if the user enters an incorrect email address? Those scenarios also need to be tested.
Test case example
Now let's explore an example of a test case for removing an old credit card number from an account.
Test case ID: TC-012
Title: Remove a stored credit card from account settings
Description: Verify that a user can successfully remove a saved credit card from their account under payment settings.
Test steps:
- Log in to the user account using valid credentials.
- Navigate to Account Settings.
- Click on Payment Methods.
- Locate the stored credit card to be removed.
- Click the Remove or Delete icon next to the card.
- Verify the removal in the confirmation modal.
Expected results:
- The selected credit card is removed from the list of payment methods.
- A success message is displayed: "Your payment method has been removed."
- The removed card no longer appears on the Payment Methods screen.
- No errors are shown during the process.
Things to consider before writing test cases
Before you dive into writing test cases, it's important to understand the context around what you're testing and why. This will help shape how you write the test cases, what to focus on, and which details are the most important.
- Type of testing: What type of testing is needed? Functional testing? Unit testing? Automated software testing? A combination of tests? You need to determine the type of testing required so you can approach the test appropriately.
- Testing tools: What tools will you depend on for completing the tests? Consider utilizing test management tools, bug trackers, and communication tools to facilitate effective collaboration and streamline processes.
- Risk and priority: Focus efforts where bugs would have the biggest impact, but that doesn't mean skip everything else. Understand the risk and prioritize your tests accordingly.
- Available assets: Review product specs, wireframes, user interface mockups, and user flows first. These help set the scene for what's to come throughout the testing process.
- Timeline: What is the deadline for testing to be completed? If time is limited, you'll need to prioritize tests accordingly in case you don't have time to complete all tests.
Write test cases that work for your team
Writing effective test cases goes beyond just filling in a template. You need to write clear, useful, and easy-to-maintain test cases from the user's perspective. By focusing on one objective per test case, maintaining consistent language, and tying each test to a specific requirement, you'll build a testing process that saves time, reduces bugs, and scales with your product.
Whether you're part of a software testing team, a developer writing your own tests, or a product manager helping shape quality standards, good test cases are a shared tool for building better software.
Test case template
The first step to improving your testing process is to standardize how you write test cases. We've created a simple test case template to help you get started. This template enables you to create multiple test cases in a single spreadsheet and helps you capture the most critical components for each test case.
Get the test case template here:
Frequently asked questions
Common questions around writing test cases.
