New techniques, tools, and processes seem to keep popping up almost every other day in the software testing field. This post will help you out on the vocabulary front by clarifying the “test scenario versus test case” dichotomy. As you’ll see, these two terms aren’t interchangeable, but they’re certainly related concepts that you need to understand.
We’ll open the post by briefly defining both terms and explaining why their meaning matters for a software-testing professional, such as a QA engineer or test analyst. With the basics out of the way, we’ll explain the specific ways test scenarios and test cases differ and show examples to illustrate.
Test Scenario vs. Test Case: A Brief Introduction
We’ll begin by getting some fundamental questions out of the way.
What Is a Test Case?
A test case is a written document that gives detailed step-by-step instructions on how to perform a given test for a software feature.
A test case typically features:
- the conditions necessary for the start of the test
- one or more inputs, if any, for the test
- the action that is to be performed
- the results of the test, which may consist of outputs or changes in the conditions of the “world”
A test case resides at the tactical level. It tells the tester what they need to do and in what order, details the outcomes they should expect.
When Should You Write a Test Case?
Inside the software development lifecycle, when it’s the right moment to write test cases? It all boils down to the methodology your team uses.
Back in the old days of waterfall, testing was a phase. It usually only started after the implementation phase was done, which, in its turn, only started after all of the design was ready, and so forth.
Under an agile mindset, such ways of working no longer fly. In agile, testing is no longer a phase but an activity. Instead of being restricted to a specific timeframe set in stone, nowadays testing happens all the time, starting as soon as possible, and it’s everyone’s responsibility.
In a nutshell: ideally, test cases are written as early as possible. If you practice TDD (test-driven development) or BDD (behavior-driven development) you’ll be writing test cases before you even write production code.
What Is a Test Scenario?
A test scenario is a more high-level description of a given concern that needs to be tested. Rather than being a step-by-step guide, test scenarios describe testing needs in very broad strokes.
Test scenarios typically live at the strategic level, which means they care about the why rather than the how. They’ll typically express the business motivation and rationale behind testing a given feature.
Why Should You Care About This Difference?
Isn’t this all very theoretical? Does this distinction actually matter in practice? Yes, it does. As a QA engineer, your job probably includes writing test cases for someone to execute. This “someone” could be yourself, other QA professionals, or, if you subscribe to the idea that testing should be everyone’s responsibility, anyone on the team, including developers.
But as we said, test cases reside at the tactical level. They’re essentially step-by-step instructions. On the other hand, test scenarios are all about strategy and connecting the test effort to a business rationale.
It’s also your job to identify and leverage additional opportunities to improve quality, such as using unscripted exploratory testing, adopting test automation, and researching and fostering the use of quality-boosting techniques and processes and tools, such as shift-left testing, linters, and more.
In other words, clearly understanding what a test scenario versus a test case is all about enables you to perform your work more effectively.
Test Scenario vs. Test Case: Some Examples
You’ve just seen the definition of both test cases and test scenarios. Let’s now see more concrete examples of each to drive the differences home more effectively.
Test Case Examples
Let’s start with a simple test case example. Imagine you have to write a test case for the shopping cart functionality of an e-commerce website.
- Starting conditions: The shopping cart is empty.
- Inputs: A product has a value of $100.
- Action: Adding the product to the cart. Also, activating a 10% off coupon.
- Results: The shopping cart should have one product, and the total value should be $90.
When it comes to manual testing, you can think of a test case as instructions that a human tester will follow when performing the test. The test case can be expressed in several different formats. Still, you’ll often see it in tabular formats, generally featuring a column so the person performing the test can input the actual results:
| Step | Expected Outcome | Actual Outcome |
|---|---|---|
| Visit the URL and verify the shopping cart. | The shopping cart is empty. | |
| Go to the home page and add product TEST PRODUCT 1 that’s worth $100, to the cart. | The shopping cart has one product. | |
| Go to the checkout page and add coupon TEST10. | The total value of the shopping cart is $90. |
The example above is deliberately simple. A real test case will often include more elements, such as:
- attached documents that are relevant for the execution of the test
- diagrams, screenshots, and other visual aids that can help the tester understand the expected outcomes
- links to documentation, private wiki entries, or Jira/GitHub issues that are relevant for the test
Test Scenario Examples
Examples of test scenarios are simpler and shorter since they’re merely high-level statements of concerns that need to be tested. Here are some possible examples of test scenarios:
- Verify the workings of the shopping cart functionality.
- Check whether authentication/authorization works correctly.
- Confirm that the demo page works as expected.
The Differences, Summarized
We’ve defined test cases and test scenarios and provided examples of both. Let’s now understand how they relate and summarize their differences.
Test scenarios give origin to test cases. You’ll typically have way more test cases than test scenarios as a logical consequence. The creation of test cases is typically more labor-intensive due to the granularity of details involved. But the creation of test scenarios can oftentimes be harder since it has a degree of ambiguity and uncertainty involved and needs to connect to the business in a way that makes sense ROI-wise.
Let’s now summarize the differences between them with a table:
| Test Case | Test Scenario |
| Tactical level | Strategic level |
| Cares about the how | Cares about the why |
| There are many per test scenario. | One test scenario gives origin to many test cases. |
| It’s executed by a tester, QA professional, or developer. | It can’t be executed but serves as higher-level guidance for decision-making. |
| It can be automated with the help of a code-based or codeless test automation tool | It can’t be automated because it’s not a set of steps |
| It can be labor-intensive to elaborate on but is objective and unambiguous | Can have some degree of ambiguity |
Test Scenario vs. Test Case in the Context of Test Automation
It’s important to understand that many terms in the software-testing lexicon often acquire different meanings in automated testing.
For example, in the NUnit framework, “test case” is an attribute that allows developers to mark a method as a test method and provide parameters to be used in a parameterized test. In a BDD (behavior-driven development) context, the word “scenario” has a slightly different meaning than what we’ve seen here. Instead of a high-level “concern,” BDD scenarios are more like specifications for the workings of a given feature, from a user’s perspective and written in natural language.
These differences in meaning shouldn’t be a major concern, but it’s important to be aware of them, so there’s no risk of miscommunication in your team.
Organize Your Testing Strategy and Reap the Benefits!
Saying that software testing is important is a huge understatement. Testing is, without a doubt, the most important activity when it comes to software quality. However, you can’t simply start testing things arbitrarily and hope to achieve great results. What you need is a strategy, and hope isn’t one.
Coming up with a winning strategy isn’t a walk in the park, but you have to start somewhere. And organizing your tests is a great first step.
In this post, you’ve learned about test cases and test scenarios, why they’re used, and the importance of distinguishing one from the other. Now the ball’s in your court. It’s your turn to make use of this information. Start organizing your testing approach, using scenarios to express the business motivation behind testing efforts and test cases to clearly express the steps and outcomes for each test.
