How to Write Test Cases with Test Case Example

There’s no one-size-fits-all for writing a good test case. There’s a lot to consider — not only between projects, but among each test within the same project. Because while they may seem like glorified to-do lists, great test cases are far more than that.

Here we’ll address common struggles related to test cases and why they happen. We’ll also provide a step-by-step guide to writing a great test case, including an example.  
 

Common Problems with Test Cases

Simply knowing how to write a test case only gets you so far. Poorly-written test cases can waste time and, depending on the product, potentially put users in danger.

Writing great test cases means that not only are all the right tests performed, but also that you maximize your ROI. To do that, we need to look at what’s going wrong, and why.

If you struggle with any of the following, you’re likely missing something:

• Accuracy of test cases — they may include ambiguous language or wrong information.
• Producing reproducible results — will two testers get the same result on the same test?
• The time it takes to write tests.
• The time it takes to train your testers — to be productive and know what to do next on their own.
• Knowing when you’re done writing tests.
• Keeping tests up to date — will they stay accurate as requirements change?

The Core of the Problem

In all of these instances, you’re probably missing clear answers to one or more of these three fundamental questions:

1. Where is your source of truth for requirements/user stories? Depending on your product and team, requirements can look very different. Some will have formal product requirements that have been documented, reviewed, and approved. Some teams use a rather informal process to document requirements. Which sometimes means they aren’t documented somewhere that’s easily accessible to testers. Or that testers may not know if they’re working with the most recent version of requirements.  
   
   The bottom line is that requirements tell you what to test. If you know what you’re testing, you know when you’re done. (By the way, using an electronic repository will solve this. Here’s one you can try for free.) 
    
2. Who will be running the tests? You need to write your test cases to your audience. Testers will vary in things like domain expertise, experience, and language fluency. A tester with a good understanding of the industry in general, and what the product is supposed to do, won’t need certain things clarified within the test case. Experienced testers also won’t need certain steps clarified. For example, the step could simply say “create a test case,” instead of listing out the steps to create one. It’s important to know exactly how much information you have to include. And if you’re working with contract testers who don’t share your native language, you need very consistent vocabulary and clear, unambiguous steps. 
    
3. What are the risks of not being perfect? Answering this tells you whether you need to cover every scenario. For example, test criteria for a GI endoscopy system you write for the Mayo Clinic would be more demanding than that for an online coloring book. The ultimate question is: if the test isn’t perfect, could someone die or be otherwise harmed? Knowing the risks helps you determine the amount of time you spend on:
   • Accuracy
   • Test coverage
   • Reproducibility

Be sure to answer all of these questions before you begin writing your test cases. 
 

How to Write Test Cases

This checklist outlines the steps you need to take to write a test case, and the guidelines that help ensure it’s written well.

Step 1. Find your requirements (or user stories.) Again, these tell you what to test. It’s critical to complete this step first. Begin each test case from a requirement.

Step 2. Create a summary for each test case. This is a clear, simple description of what the test is. If you use a test case management solution, this will appear like a title in your overview of your tests. Make it easy to distinguish one from another.

Step 3. Include a description of goals. Help the tester understand the big picture.

Step 4. Determine the starting conditions and any setup or equipment your test relies on. Picture a recipe for baking a cake. “Pre-heat the oven to 350 degrees” is a pre-condition. Two greased 9” round cake pans are required equipment. Do this for yourself by identifying necessary setup:

• Do you need special equipment for the test?
• Does the test need a clean install?
• Does it need specific database contents?
• Do you handle sensitive data (like credit card processing)?
• What assumptions do you have about other tests that might have been run?
• Does the test require specific test data or parameters?

Use this information to be clear and thorough in your steps.

Step 5. Write clear, simple steps. If you can, attach an image of a screenshot or mockup to help clarify. Here are the criteria that will make the difference between a good test case and a poor one:

• Write with clarity, concision, and precise language.
• Ensure it meets the criteria of tester independence. Would any two testers get the same results? If you say enter a “large amount” into a field, one tester could enter 100 and another 1000. Can it be that ambiguous, or do you need to be clearer?
• Determine what assumptions have been made in the step. What steps have already been taken? What’s in the database? Is this the first time a user has logged in? Write enough steps for the kind of tester who will be running the test. 

Step 6. With those same criteria, also include expected results — this is how the tester knows whether the test passed or failed. To continue the recipe analogy, for the step “Remove the cake from the oven after 45 minutes”, an expected result would be, “The top of the cake is brown, and the sides have pulled away from the pan.”

This outlines the basics of writing a test case well. You can include other parameters, as will be shown in the following example.

BLOG: GET MORE TIPS FOR WRITING TEST CASES IN SOFTWARE TESTING >>

Test Case Example for Manual Testing

Here is a screenshot of a test case created in Perforce TCM. You can see all the elements of the steps outlined above.

Additionally, it provides other information you may choose to include.

Leverage your test case tool’s ability to support custom fields, requirement traceability, and configurable workflow to help you organize and manage your testing efforts.

You can use this additional test meta-data to help:

• Determine the best person to run the test – functional area, type of test.
• Plan to test around limited shared resources – hardware, database instance.
• Be more efficient by grouping tests with similar setup requirements – platforms, user personas.
• Analyze risks – complexity, risk of harm.
• Provide status updates – test coverage, productivity.
• Identify out-of-date or stale tests – suspect flag, workflow status.

What additional information you include with each test case will depend on your project template and test management process.

BLOG: HOW TO WRITE (BETTER) TEST CASES IN JIRA >>

The Easier Way to Write Test Cases

All of this information will help you craft better test cases. But they can be even easier to create when you switch from managing tests with spreadsheets and Word docs to a proper test case management solution.

Perforce TCM lets you write, execute, and track tests with ease. Use it on its own for test management or as part of the Perforce ALM (formerly Helix ALM) suite. Even pair it with your existing tools, including Jira.

You can try it out for free. Use the buttons below to download your 30-day trial or watch a demo of Perforce ALM to get a complete overview of the solution.

Manage your test cases for free.  See Perforce ALM in action.