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 systematic 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. 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 -

Test Case Philosophies

The scope and intent of test cases can be very divisive. On the one hand, you have people who think test plans should be minimal; on the other, test cases should be very detailed and include rigid step-by-step instructions. I believe both are correct; both philosophies have their place, and your test cases should fit the organization's needs. Above all, your test cases should be easily understood and repeatable by anyone in your organization.

Let's look at an example situation where you may need less verbose instructions. You're working on an e-commerce platform and need to create an order. The steps should be relatively intuitive. Add an item to the cart, go to checkout, and place an order.

Now, let's look at a situation where you want to be more specific. You're working on an invoicing feature that takes orders with given parameters (age, status, etc) and generates invoices. This scenario can require very granular steps. What status does the order need to be? Are we looking at the age of the order? This situation deals with cash flow; if any of it is wrong, the company could be out a lot of money if it needs to be corrected.

Now that we have that out of the way let's get into what makes a test case. This way, we know the end goal and can jump into some techniques to help you craft test cases. This example should also allow you to understand what you can trim to better work for your specific needs.

Contents of a Test Case

  • Unique Title or ID:

    You'll need something to refer back to if you need to revisit the test.

  • 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/Preconditions:

    Here, you would put any information or needed setup for the test. For example, you're testing a login form. Something you would put here is 'Have a user created.'

  • Steps:

    As the name implies, this section contains all the steps the tester should take to determine if the software satisfies requirements.

    This section is where your test case philosophy will likely differ depending on the organization.

  • Expected Results:

    This field contains the requirements and what the result should be. When the tester finishes following all the test steps, what should they expect?

  • Actual Results:

    The tester would fill this field in, either reporting that the results matched the expected outcome or what went wrong.

  • Status:

    A simple pass/fail indication of the status of the test

  • Priority:

    Rate how critical this test is. For example, a high-priority test likely deals with money, while a low-priority test may be for a UI feature that doesn't change the functionality.

  • Notes/Remarks:

    Anything you found testing that may be beneficial.

Example Test Case

Now, I want to show you an example test case using the template from above. I've been asked various forms of this question throughout my career. First, I'm asked by the interviewer what a test case is, then I'm asked to create and walk through one for an item they provide me. For whatever reason, it tends to be food-related, so I'll stick with that.

Title:

  • Craft a PB&J sandwich

Description:

  • The user is hungry and wants a sandwich.

Setup/Requirements:

  • The user must have the following food ingredients:

    • Jar of Peanut Butter
    • Jar of Jelly
    • Two slices of bread

  • The user must have a knife suitable for spreading the ingredients

  • The user must have a plate to place the sandwich

  • The user must have a Kitchen Counter

  • The user must have a Kitchen Sink

Steps:
  1. Place the plate on the kitchen counter
  2. Place the two pieces of bread on the plate
  3. Open the jar of peanut butter
  4. Use the knife to scrape peanut butter from the jar onto one slice of the bread
  5. Spread the peanut butter evenly
  6. Bring the knife to the sink and wash the peanut butter off
  7. Place the knife again next to the plate
  8. Close the jar of peanut butter
  9. Open the jar of jelly
  10. Use the knife to scrape jelly from the jar onto the other slice of bread
  11. Spread the jelly evenly
  12. Bring the knife to the sink and wash it off
  13. Place the knife away
  14. Close the jar of jelly
  15. 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
Status:
  • Passed

Minimal Test Case

What would this look like if we went with a more minimal approach? With this, we're expecting the user's actions to be intuitive. I'd change the steps to look something like this:

Steps:

  1. Place bread on a plate

  2. Apply peanut butter to one slice of bread

  3. Apply jelly to the other slice of bread

  4. place the bread together

This approach relies on the user knowing how to perform certain aspects of the test. For example, we expect the user to know that the jelly or peanut butter only goes on one side of the bread. We expect the user to realize they must open the jars and use a knife to spread the jelly.

Closing Thoughts

Both of these have their merits, and the goal should be that they are understandable by anyone and repeatable. The benefits of both styles include allowing the tester to document the requirements and providing direction and time for exploratory testing. Test cases and exploratory testing, where you're going off script, are complementary; these methods will enhance each other. Once you've tested this manner, you could move on to automating the test cases. Test cases are also a great way to identify testing coverage. As you can see, the test case foundation can bring up quality across the board.

Lastly, test cases are only one of the options and, in some cases, may be detrimental. If your test isn't repeatable or meant to be a script for others to follow, then mind maps, diagrams, high-level outlines, and storyboards may be a better fit. The tester should make this decision during test design.