So what is a test case? In the simplest terms, it's a single executable test aiming to achieve a specific testing objective. They bring a methodical approach to what would otherwise be a haphazard approach. A test case contains a set of conditions or variables you can think of as step-by-step instructions. A tester uses these to determine whether the software satisfies requirements and functions correctly. They are written during the test design phase and executed during the test execution phase.

By failing to prepare, you are preparing to fail. - Benjamin Franklin

Something worth noting is that software terminology can be confusing. This point is especially true in software testing. To help avoid uncertainty, I'd like to point out that test cases may informally refer to three different types of test cases. The first, known as a Formal Test Case, is what we described in the paragraph above. It is the proper industry standard. The second is known as an Informal Test Case. This type of case, as the name implies, is informal. Instead of setting out requirements, the user records activities and results after the fact. The third isn't a test case at all, although it is all but a guarantee you'll see it referred to as one in your career. It's called user stories or scenario testing, they can be beneficial, and you'll soon see another post about them here on this site. However, the bottom line is that unless specified, 'test case' should always refer to Formal Test Cases.

With that out of the way, let's get into what makes a test case. First, what does a good test case look like or contain?

Contents of a test case

  • Unique Title or ID
    • You'll need something to refer back to if a test ever needs to be revisited
  • Test Category
    • This identifier helps with organization and knowing which sections have the most coverage
  • Author
    • It can be essential to know who wrote what
  • Description
    • This section should include details of the test, why it's needed, and what it goes over
  • Setup/Requirements
    • Here you would put any information or needed setup for the test. For example, maybe you're testing a login form. Something you would put here would be 'Have a user created.'
  • Steps
    • As the name implies, this would be the section containing all the steps the tester should take to determine if the software satisfies requirements
  • Expected Results
    • This field contains what those software requirements are. When the tester finishes following all the test steps, what should they expect?
  • Actual Results
    • This field would be filled in by the tester, either reporting that the results matched what was expected or what went wrong
  • Pass/Fail
    • A simple indication of the status of the test
  • Notes/Remarks

I want to show you an example of a good test case, but as a bonus, I'm going to do it in a way that often comes up in interviews. Throughout my career, I've been asked various forms of this same question. First, I'm asked what a test case is, then I'm asked to create and walk through one for an item they provide me. For whatever reason, at least in my experience, it tends to be food related, so I'll stick with that.

Don't worry about Title, Category, or Author. The description is that I am hungry and want to make a PB&J sandwich. So I want you to think about the answers before skipping ahead: the Setup, Steps, Expected Results, and Actual Results.

So do you think you got this? Let's take a look at how this should be written out.

Setup/Requirements
  • Jar of Peanut Butter
  • Jar of Jelly
  • Bread
  • Knife
  • Plate
  • Kitchen Counter
  • Kitchen Sink
Steps
  1. Grab a plate and place it on the kitchen counter
  2. Go to the pantry and grab the bread
  3. Open the bag holding the bread
  4. Remove two pieces of bread and put them on the plate
  5. Close the bag containing the bread
  6. Place the bag of bread back in the pantry
  7. Grab the knife and set it next to the plate
  8. Grab the peanut butter from the pantry
  9. Open the jar
  10. Use the knife to scrape peanut butter from the jar onto one slice of the bread
  11. Spread the peanut butter evenly
  12. Bring the knife to the sink and wash the peanut butter off
  13. Place the knife again next to the plate
  14. Close the jar of peanut butter
  15. Place peanut butter back in the pantry
  16. Open the fridge
  17. Grab the jar of jelly from the fridge and place it on the counter
  18. Close the fridge
  19. Open the jar of jelly
  20. Use the knife to scrape jelly from the jar onto the other piece of bread
  21. Spread the jelly evenly
  22. Bring the knife to the sink and wash it off
  23. Place the knife away
  24. Close the jar of jelly
  25. Open the fridge
  26. Place the jar back
  27. Close the fridge
  28. Place the slice of bread with jelly on top of the other slice of bread with the peanut butter face up.
Expected Result
  • You now have a yummy PB&J sandwich
Actual Result
  • You indeed made a great sandwich

Now that might seem like many steps, but if there's ever something to remember in creating a test case, it's never to assume anything. Don't expect the tester, for example, to wash off the knife.

Now you should have a basic understanding of a test case and how to create one. Going back to the beginning, I mentioned another type of testing user stories or scenario testing. Be sure to check back soon for my next post on that.