So what is a test case? In simplest terms, it’s a single executable test whose purpose is 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 and can be thought of as a set of step-by-step instructions. These are used by a tester to determine whether the software satisfies requirements and functions properly. 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 is especially true in software testing. To help avoid uncertainty I’d like to point out that it’s possible when someone asks about test cases they may actually be referring 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 true 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, activities and results are simply recorded after the fact. The third really 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 extremely helpful and in fact, you’ll soon see another post about them here on this site. However, the bottom line is that unless specified “test case” should always be referring 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 contain or look like?

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 helps with organization as well as knowing sections have the most coverage
  • Author
    • It can be important to know who wrote what
  • Description
    • This section should include details of what the test is for, 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 of 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'm going to 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 what I want you to think about the answers to before skipping ahead are 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
  • Steps
    • Grab a plate and place it on the kitchen counter
    • Go to the pantry and grab the bread
    • Open the bag holding the bread
    • Remove two pieces of bread and place them on the plate
    • Close the bag holding the bread
    • Place the bag of bread back in the pantry
    • Grab the knife and set it next to the plate
    • Grab the peanut butter from the pantry
    • Open the jar
    • Use the knife to scrape peanut butter from the jar onto one slice of the bread
    • Spread the peanut butter evenly
    • Bring the knife to the sink and wash the peanut butter off
    • Place the knife again next to the plate
    • Close the jar of peanut butter
    • Place peanut butter back in the pantry
    • Open the fridge
    • Grab the jar of jelly from the fridge and place it on the counter
    • Close the fridge
    • Open the jar of jelly
    • Use the knife to scrape jelly from the jar onto the other piece of bread
    • Spread the jelly evenly
    • Bring the knife to the sink and wash it off
    • Place the knife away
    • Close the jar of jelly
    • Open the fridge
    • Place the jar back
    • Close the fridge
    • Place the slice of bread with jelly on top of the other slice of bread with the peanut butter face up.
  • Expected Results
    • You now have a yummy PB&J sandwich
  • Actual Results
    • You indeed made a great sandwich

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

Now you should have a basic understanding of what a test case is 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.