Use Case and Test Case: What’s the difference?

The terms “use case” and “test case” are sometimes used interchangeably in the IT development world, and for good reason. Both terms refer to a way of checking if users’ interactions with a product or system occur in an intended way. The difference lies in creator intent.

In a sentence, a use case describes the user problem, a system of business- and user-requirements needed to solve it, and how users will interact with that system. On the other hand, a test case describes the experiment analysts use to evaluate how well that system solves the user’s problem.

What is a use case, in more detail?

Ivar Jacobson coined the term “use case” in 1992 in a software engineering context, which is what most IT people are familiar with. However, business analysts and organizations have adapted “use cases” to a way of putting users at the center of company resource allocation. In this article I want to focus on “use case” as the latter, business jargon, rather than as a system.

If you break it down by each word, the implied meaning is clear. “Case” means “an instance or example,” and “use” means “application of a tool or idea.”

In a business context, a use case is a narrative and persuasive document that aims to describe the step-by-step process a user pursues in their life. The use case “story” begins with a system in which a problem is faced and ends with its resolution via a proposed product or service. In cases where customers repurchase the product or service, additional steps describe why the problem reoccurs and if reoccurrence poses a business risk.

We can break use cases down into their component parts. Using these parts helps keep the narrative concise and precise. One of the challenges with use cases is finding the right amount of detail to include in your story:

Parts of a use case

• Actor – anyone or anything that uses the system in which the products are located
• Stakeholder – someone or something with vested interests in the system in which the products are located
• Primary Actor – anyone or anything that uses the system to achieve a goal
• Preconditions – what must be true or must happen before and after use of the system
• Triggers – the event that catalyzes the use case
• Basic Flow of Success Scenario – use case in which nothing goes wrong
• Alternative flow – use case when a problem occurs in the system

For example, let’s envision a use case flow of dishwashing with Jorge. To create a useful use case, we first need an example of the case without a new product This will help concretize a definition of the system.

1. Jorge opens the dishwasher.
2. Jorge puts dirty dishes into the dishwasher.
3. Jorge puts dishwashing soap into the dishwasher.
4. Jorge closes the dishwasher.
5. Jorge starts the dishwasher.
6. Jorge empties the dishwasher.

Pain points

I think an important step for any successful development process is to also include pain points in the use case. Pain points show where the user may not get the optimal experience and pose a risk of him/her wanting avoiding your system (or product or feature).

To write pain points, we must elongate the user case flow to identify where those pain points might be. If we can identify the pain points, it’s much easier to create value.

1. Jorge opens the dishwasher. Pain point: Jorge must bend down to open the dishwasher door, a motion unpleasant for his lower back.
2. Jorge puts dirty dishes into the dishwasher. Pain point: Some food from the dishes falls on the ground when Jorge moves the dishes, which he must clean up.
3. Jorge puts dishwashing soap into the dishwasher. Pain point: Jorge must again bend down to put soap in the dishwasher. He often has to move the dish holding trays in order to access the dishwashing soap compartment.
4. Jorge closes the dishwasher. Pain point: again, Jorge must bend down.
5. Jorge starts the dishwasher. Pain point: none.
6. Jorge empties the dishwasher. Pain point: bending down.

Now that the use case flow is clear, let’s identify our component parts:

• Actor – anyone who uses a dishwashing machine
• Stakeholder – dishwashing machine makers, dishwashing machine users
• Primary Actor – Jorge
• Preconditions – there must be dirty dishes. Those dishes must be clean after going through the machine.
• Triggers – the event that catalyzes the use case
• Basic Flow of Success Scenario – please see below
• Alternative flow – please see below

We can thus introduce our product or feature into the system to show in what way it brings added value.

Introduce the product

Let’s imagine our product is a “dish hole” in which Jorge slides his dirty dishes. The dish hole then sorts his dishes before putting them into the dishwasher. It begins washing once full with soap that comes from an automatic soap dispenser. (This is a silly example for demonstration purposes only!)

1. Jorge opens the dishwasher. Pain point: Jorge must bend down to open the dishwasher door, a motion unpleasant for his lower back.
   • The dish hole removes the bending motion by allowing him to place the dishes while standing near a kitchen sink.
2. Jorge puts dirty dishes into the dishwasher. Pain point: Some food from the dishes falls on the ground when Jorge moves the dishes, which he must clean up.
   • The dish hole is located next to the sink, so there is no way for food to fall on the ground.
3. Jorge puts dishwashing soap into the dishwasher. Pain point: Jorge must again bend down to put soap in the dishwasher. He often has to move the dish holding trays in order to access the dishwashing soap compartment.
   • There is an automatic soap dispenser in the dish hole.
4. Jorge closes the dishwasher. Pain point: again, Jorge must bend down.
   • There is no need to close the dishwasher when using the dish hole.
5. Jorge starts the dishwasher. Pain point: none.
   • The dish hole has a natural starter button when it senses the dishwasher is full.
6. Jorge empties the dishwasher. Pain point: bending down.
   • This pain point is not solved since the dish hole is only involved in the system leading to wash, not afterwards.

Advantages of a use case

It’s easy to see that use cases help developers and analysts identify opportunities in their customers’ lives. This is their purpose, after all.

But there are a few hidden advantages. For starters, use cases help different departments align on objectives.

Fifty years ago, it would not have been necessary to understand customers to the same degree. In an analogue world, markets were much less dynamic. It was more or less clear what customers needed. But today, a methodology for refining exactly what it is the user needs will set you apart in the market.

It’s also a helpful tool too make sure teams agree on requirements, as part of requirement analysis.

What is a test case?

One way of thinking about a test case is as a measurable use case that examines the effectiveness of a product. In other words, where a use case is about envisioning a product in its element, a test case is the actual process of seeing if the product works.

A test case looks more like a list of instructions written in a cryptic way. They’re intended to be high-level in order to prevent the user from purposefully producing a result due to cognitive bias. For example, let’s continue to use our dishwasher situation from above:

Action	Input	Expected Output	Actual Output	Test Result	Comments
Put dishes into the dish hole	Inserted dished	Dishes arranged in dishwasher	Broken dishes poorly organized in dishwasher	Fail	This was a silly idea…
Empty the dishwasher	Pull handle to open machine and put dishes away	Dishes are clean and properly placed on shelf	Dishes are smashed and dirty	Fail	A really, really silly idea…

As you can see, the steps are usually more limited. In a test case, we’re looking less at conceptualizing how a product will fit into someone’s life. Test cases simply want to beat an idea on the head to see if it cracks or holds firm.

Advantages of a test case

The advantages of having a test case are many. The most important is that they act as a checkpoint before software teams put a large amount of effort into production. To summarize: you prevent spending money, time, and resources on a project that simply doesn’t have any use by using a use case. On the other hand, sometimes ideas that have use in theory prove to be ineffective in reality.

A great example of this is Google Glasses.

In theory, the use case suggested that people would get enormous value in having information at any given moment, but the test case showed that nobody wants to wear burdensome glasses. The value they bring is not enough to overcome the bother of having them.

So they failed.

Side-by-side Comparison: Use Case vs Test Case

Use Case	Test Case
Written before creating product	Performed after creating product
Theoretical	Practical
Checkpoint before developing prototype or MVP	Checkpoint after developing prototype or MVP
Prevents fruitless product investigations	Prevents large expenditure to go to mass market