September 22, 2020

How to Write Examination Cases — With Example

There's no one-size-fits-all for writing a good test case. There's a lot to consider — non simply between projects, but amidst each test inside the same projection. Because while they may seem like glorified to-exercise lists, great test cases are far more than that.

Here we'll accost common struggles related to exam cases and why they happen. We'll also provide a pace-by-footstep guide to writing a cracking test instance, including an example.

Common Issues with Test Cases

Just knowing how to write a examination example merely gets you then far. Poorly-written examination cases can waste fourth dimension 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 practise that, nosotros demand to await at what's going incorrect, and why.

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

  • Accuracy of exam cases — they may include ambiguous linguistic communication or incorrect 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 practice next on their ain.
  • Knowing when you lot're done writing tests.
  • Keeping tests up to date — will they stay accurate equally requirements change?

The Core of the Problem

In all of these instances, you lot're probably missing clear answers to ane 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 await very different. Some will take formal product requirements that have been documented, reviewed, and approved. Some teams use a rather breezy process to document requirements. Which sometimes means they aren't documented somewhere that'south easily accessible to testers. Or that testers may non know if they're working with the most recent version of requirements.

    The bottom line is that requirements tell yous what to test. If you lot know what you're testing, you know when you lot're done. (By the way, using an electronic repository will solve this. Here's one yous can attempt for gratuitous.)

  2. Who will be running the tests? You lot demand to write your test cases to your audience. Testers will vary in things like domain expertise, experience, and language fluency. A tester with a proficient understanding of the industry in full general, and what the product is supposed to do, won't need certain things clarified within the examination case. Experienced testers also won't need certain steps clarified. For example, the step could simply say "create a test example," instead of listing out the steps to create 1. It's important to know exactly how much information y'all take to include. And if you're working with contract testers who don't share your native language, you demand very consequent vocabulary and articulate, unambiguous steps.
  3. What are the risks of not beingness perfect? Answering this tells you whether you lot need to cover every scenario. For example, test criteria for a GI endoscopy arrangement you lot write for the Mayo Dispensary would exist 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 yous determine the amount of time you spend on:
    • Accuracy
    • Test coverage
    • Reproducibility

Exist sure to answer all of these questions before you brainstorm writing your exam cases.

How to Write a Transmission Exam Example

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

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

Step ii. For each test case, create a summary. This is a clear, simple description of what the test is. If you lot utilise a test case direction solution, this will announced like a title in your overview of your tests. Make information technology easy to distinguish one from another.

Step 3. Include a description of goals. Aid the tester sympathise the big picture.

Step four. Make up one's mind the starting weather and whatever setup or equipment your examination relies on. Picture a recipe for baking a cake. "Pre-heat the oven to 350 degrees" is a pre-condition. Two greased nine" circular cake pans are required equipment. Practise this for yourself by identifying necessary setup:

  • Do you need special equipment for the exam?
  • Does the test need a clean install?
  • Does it need specific database contents?
  • Do you handle sensitive data (similar credit card processing)?
  • What assumptions practise you lot have well-nigh other tests that might have been run?
  • Does the test require specific test data or parameters?

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

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

  • Write with clarity, concision, and precise language.
  • Ensure information technology meets the criteria of tester independence. Would any two testers get the same results? If you lot say enter a "large amount" into a field, one tester could enter 100 and some other k. Tin can it exist that ambiguous, or do you need to be clearer?
  • Determine what assumptions have been made in the footstep. What steps have already been taken? What's in the database? Is this the first time a user logs in? Write enough steps for the kind of tester who will be running the examination.

Step 6. With that same criteria, likewise include expected results — this is how the tester knows whether the test passed or failed. To continue the recipe illustration, for the pace "Remove the cake from the oven after 45 minutes", an expected result would be, "The peak of the cake is brown, and the sides have pulled away from the pan."

This outlines the basics of writing a test instance well. You can include other parameters, every bit volition 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 exam case created in Helix TCM. Yous can see all the elements of the steps outlined above.

test case example

Additionally, information technology provides other data you lot may choose to include.

Leverage your test case tool'southward ability to back up custom fields, requirement traceability, and configurable workflow to assist you organize and manage your testing efforts.

You lot can use this additional exam meta-data to help:

  • Decide the best person to run the test – functional surface area, blazon of examination.
  • Programme testing around limited shared resources – hardware, database example.
  • Be more efficient by grouping tests with similar setup requirements – platforms, user personas.
  • Analyze risks – complication, risk of harm.
  • Provide status updates – exam coverage, productivity.
  • Identify out-of-date or stale tests – suspect flag, workflow condition.

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

[Weblog: HOW TO WRITE (Better) TEST CASES IN JIRA >]

Write Fifty-fifty Easier Test Cases

All of this information will help you craft better examination cases. But they can be fifty-fifty easier to create when you switch from Microsoft Office to a examination instance management solution.

Helix TCM lets y'all write, execute, and rail tests with ease. Use it on its own for test direction or every bit part of the Helix ALM suite. Even pair information technology with your existing tools, including Jira.

And you lot can endeavor it out for costless. Utilize the buttons below to download your 30-day trial, or watch a demo of Helix ALM to learn more than about the scope of the software.

manage your test cases for freemeet helix alm in action

Paula Rome

Senior Product Managing director, Perforce

Paula is a Senior Production Manager for Helix ALM. With a diverse groundwork, including roles from computational physicist to startup founder, she believes software should first and foremost make our lives easier. She specializes in application lifecycle management, with an accent on testing and requirements direction. When out of the part, she's always looking for a adventure to play inline hockey.