People often mix up terms like test suite and test cases. And if you’re one of them, don’t worry: this post is for you.
In short, a test case is the smallest piece of testing you can have when creating automated tests. And several test cases together make up a test suite, which you can additionally use to manage and also execute the test cases together.
We’ll open the post by defining “test case.” You’ll see examples of test cases both in manual and automated software testing. Subsequently, we’ll cover the term “test suite.” You’ll come to understand what it is, see examples, and learn how this concept relates to test cases. Afterward, we’ll also cover yet another related term, “test run.” And lastly, you’ll have a more robust understanding of these important concepts in the software testing field. Let’s begin.
Test Suites and Test Cases: What’s the Difference?
We can describe the relationship between test suites and test cases straightforward: A test suite is a collection of test cases. But what is a test case? Simply, think of a test case as the smallest unit in the hierarchy of a testing approach. If that doesn’t make a lot of sense, don’t worry, we’ll explain both terms in more detail next.
What Is a Test Case?
We said you could think of a test case as the most fundamental part of a software testing approach’s hierarchy. It is what most people would consider “a test.”
What does a test case include? Before all, a test case has a sequence of steps that need to be carried out during the test execution. However, executing a bunch of steps isn’t enough. Therefore, a test case also needs to contain some verification in which the expected outcome is compared to the actual result. Consequently, the result of that comparison is what will tell you whether the test has passed or not.
Pre-Condition and Post-Condition
Pre-condition is a condition that should be true to test a case. For example, to test the checkout feature of an online shopping application, the user should’ve at least one item in the cart.
On the other hand, post-condition is a condition that is true after the action is complete, in other words, the outcome of the test case. For example, an application should display whether the transaction was a success or failure after a user has completed the payment.
Test Templates
Following a standard makes any process better. A test template is a document that provides information about the test case, its design, and development, and also acts as a checklist for a tester. A typical template should have the following details:
- Test Name/Title/ID
- Priority
- Test Designer’s Name
- Test Version and date the test was designed
- Test Description
- Name of Tester
- Date of test execution
- Pre-condition and Post-condition
- Test Environment information
- Expected Output
- Actual Output
- Test Status (Pass/Fail)
Expand Your Test Coverage
An Example of a Manual Test Case
Regular readers of this blog will know that we’re champions of test automation. However, that doesn’t mean we’re 100% against manual testing. Quite the contrary: Manual testing still has a role to play in a well-balanced testing strategy. Let’s see an example of what a manual test case could look like.
Since we’re talking about manual testing, that means that this test case must consist of steps with enough detail that a tester—or whoever is performing the test—should be able to carry it out without much problem.
For our test case example, let’s use a website we’ve used in the past: the demoblaze.com demo site:
Since this is an e-commerce site, testing the shopping cart functionality is of paramount importance. So, here’s what a manual test case for that could look like:
| Test Step | Expected Outcome | Obtained Outcome |
| Access the URL https://demoblaze.com | The “Demo Blaze” site should be displayed on the browser. | |
| On the Categories menu on the left, click on Laptops. | The product listing should be updated, displaying only laptops. | |
| Click on the first product (Sony VAIO i5) | The product’s details page should be displayed. | |
| Click on the Add to cart button. | The window should display an alert saying “Product added.” | |
| Click on the Cart option on the main navigation menu. | The cart page should be displayed, showing the laptop as the only product in the cart. It should display the picture of the laptop, its description (Sony VAIO i5), its price ($790), and a link to delete the item. The cart total should be displayed as $790. |
An Example of an Automated Test Case in JavaScript
What does a test case look like when it comes to automated testing? Well, it really depends on what type of testing we’re talking about. If we’re talking about end-to-end testing, for instance, a test case could refer to a single testing session capture by a record-and-playback tool.
What if we’re talking about unit tests? In this case, we could think of a single test method as a test case. The following code example shows a unit test in JavaScript, written with the Jest framework:
it('should be instance of Car', () => {
expect(newTruck()).toBeInstanceOf(Car);
});
What Is a Test Suite?
Having defined what a test case is and given examples, we’re ready to tackle the next term.
In short, we can say a test suite is a collection or container of many test cases related to each other. Grouping your test cases into adequately named suites makes it easier to manage them. You can group tests into suites according to several criteria:
- by type of test (e.g., integration tests vs. unit tests)
- by execution time (e.g., slow vs. medium vs. fast running tests)
- finally, by modules or areas in the application
What a test suite looks like in practice will depend on the type of testing. If we’re talking about manual, scripted testing, a test suite can be as simple as a folder containing word documents, or it can be a more sophisticated approach. In the context of a unit test framework, a test suite can be a class, module, or another code artifact meant to group a bunch of unit tests.
An Example of Manual Test Suite
As you’ve seen, a test suite is nothing more than a collection of related test cases. So, let’s imagine a test suite which contains the test case seen in the previous example—expressed as a table—and more test cases.
| TEST SUITE: SHOPPING CART | |
| TEST CASES | GOAL |
| Adding a single product to empty cart | Verify whether the cart correctly handles receiving the first item |
| Adding two products to empty cart | Verify whether the cart correctly handles receiving two items |
| Removing an existing product from cart | Check whether the functionality of removing items works as expected |
| Adding two instances of same products to cart | Verify whether adding two instances of the same item works as expected |
An Example of Automated Test Suite
Let’s now see what a test suite might look like in the context of automated testing. Here’s an example taken from Jest’s documentation page:
const myBeverage = {
delicious: true,
sour: false,
};
describe('my beverage', () => {
test('is delicious', () => {
expect(myBeverage.delicious).toBeTruthy();
});
test('is not sour', () => {
expect(myBeverage.sour).toBeFalsy();
});
});
As you can see, the code above makes use of the keyword describe. This keyword is actually a function that receives two parameters:
- a string, describing what we’re testing;
- and a function, expressing the tests themselves
The code above uses the arrow-function syntax to express two tests as calls to the test function—which, in its turn, also takes a string and a function as parameters. So, we can say the code above contains a single test suite that stores two test cases.
After running the test, we see Jest’s output indicating that we have one test suite, two test cases, and that they all passed:
What About a Test Run?
A test run is an execution of one or more test cases. It is the moment of truth when all testing efforts are realized. After creating your test cases and grouping them into test suites, you must decide which tests will be executed. To do that, there are many different criteria you can use to decide. You might need to run only the test related to the most recent features. Or maybe, during the nightly build, you might want to run the integration tests along with the slower portion of the unit tests. You might decide to either test only the happy flow test cases or the sad flow ones, or both. If you work in a highly regulated industry like finance, you might need to run certain test cases additionally to prove compliance with regulations.
A test run is all about deciding which test cases are to be executed and then making sure they’re run.
Test Script
A test script is a detailed line-by-line description containing the steps involved in carrying out the test. Test scripts are the core of automated testing as they are the source of truth for the system to know what action to perform. Additionally, these scripts can also include the expected outcome of a test so the system can validate if a test passed or failed. In some cases, you might find different ways to test a scenario using different test scripts. In such cases, you can link multiple test scripts together.
Test Case vs. Test Script
On a high level, how test cases and test scripts are defined might make one think they are the same. However, there’s a difference between them.
Test cases are a step-by-step procedure that a tester has to follow in manual testing. A test case is a document created by a tester and is used to test a specific feature of a product. It is mostly English language-like. On the other hand, test scripts are a part of automated testing as they contain step-by-step instructions for the testing system to perform. They come in the form of code that can be written in different programming/scripting languages. In a simple sense, test cases are to manual testing what test scripts are to automated testing.
Test Suite and Test Cases: Understand Them To Scale Your Test Automation Approach
At this point, you’ve learned the definitions of the terms “test case” and “test suite.” Subsequently, you’ve learned the relationship between the two concepts. As you’ve seen, a test case is the most basic part of a testing approach. A test suite, on the other hand, is a collection of test cases. You group your test cases into suites to make it easier for you to manage them. Finally, you’ve also learned about test runs and how they differ from the two previous concepts.
Furthermore, the post also offered practical examples of test suites and test cases, both in a manual and automated testing scenario. In the case of the automated test cases, I’ve shown examples written in JavaScript using the Jest framework.
Managing your tests efficiently is certainly important when your organization is a fast-growing one. It might be easy to manage a testing strategy when you have few people who create few tests. As your company starts to grow and you start to onboard more new people, the number of test cases can increase dramatically, in which case managing them can become quite challenging. And if you allow test maintenance to become a burden, you risk people on your team losing faith in the testing strategy.
If that’s the situation you find yourself in—that is, needing more organization in your testing strategy—TestOps might be the answer you’re looking for. TestOps or testing operations is the discipline of managing the testing processes and people for maximum efficiency. It helps you deliver high-quality applications fast while allowing your organization to grow in a healthy, non-chaotic way.
