A Brief Guide to Use Cases and Use Case Testing

In the magnificent and complicated world of QA services, there are many techniques for verifying that the software meets a user’s needs. One of them is use case testing. In this entry, we will cover what a use case and use case testing are, how to execute a use case-based review, and what advantages use case testing offers. All these with a bunch of examples, of course.

Use Case: Definition and the Basics

A use case is a record of interactions between an actor and a system. The main terms you should understand here are:

• Interaction – a mix of actions performed by the actor and the response of the system.
• Actor – someone initiating the interaction, the first contact in further communication. It can be a user, another system, an organization, etc.
• System – the software with which an actor interacts. It responds to user actions by furthering the interaction/offering a solution to a user query.

In its basic form, a use case can be perceived as a dialog:
– Actor: wants to log into their account. They input their credentials (which is the interaction).
– System: responds by verifying the credentials and letting the actor pass to their page.

Who Works With Use Cases?

Use cases are created for listing possible user actions and verifying intended system functionality. They have primary importance for:

• Stakeholders, who can use this document to better grasp software requirements. For instance, use cases can be gathered into an outline of software functions and performance. Which can be presented to the stakeholders to summarize available operations.
• Developers, who can utilize use cases as guidelines for organizing system requirements. For example, a use case dictates the login function. Thus, a developer needs to code the module responsible for its successful completion.
• QA specialists, who apply use cases as a basis for writing test cases. Since the former define the process flow, pointing out where things can go wrong becomes easier. When you have a user/system roadmap, determining how and where potential issues can occur is much more efficient.

Who Writes Use Cases?

With the above in mind, use cases can be written by:

• Business analysts – use cases define required functionality. So, when BAs write use cases, they set up software boundaries, core functions, and user needs.
• Developers – as mentioned before, with use cases, developers can understand what is expected of the system. Thus, they can create a piece of code within a system that is responsible for a particular use case.
• QA engineers – now, typically, QA agents are not responsible for creating use cases. As they are involved in testing, which comes after the development, by that time, this document is already completed.

However, not involving QA experts in use case creation can become a vice. It is quite common for QA to be introduced to the project dev much later. While they have the knowledge needed to better define a potential use case. So, it is not a QA specialist’s duty to define project requirements. But when document requirements do not include use cases, QA agents can come up with their own to adapt better test cases from them.

Use Case and Test Case, Test Scenario, User Story

Now, to avoid the overspill of food for thought, let us recap some testing-related terms.

• Use case – a goal-oriented list of steps taken by the user to reach their target within a system. It focuses on understanding user and system behaviors.
• Test case – a description of steps that a QA expert needs to take to test a system function. It focuses on validating the intended performance of a function.
• Test scenario – a record of functions that can be tested (often comprises a set of test cases). For instance, ‘Test that a user can log into their account’. Within this function, there are numerous sub-functions as well: is the user able to input their data; what happens when an invalid password is typed; does the system redirect the user to the correct page, etc. Test scenarios focus on defining features that constitute software functionality and should be tested.
• User story – a statement describing a software function from the user’s perspective. Typically represented as a sentence defining: an actor who wants to do something (user, admin, SMM, etc.); that actor’s goal; and the actor’s reasoning. For example, ‘As a user (actor), I want to download music (goal) to listen to it offline (reason)’. User stories focus on prioritizing the development of features a user finds valuable.

What Is Test Documentation and Why Do We Need It?

You may get a bit lost in all this terminology. So, the main defining feature of a use case is that its focal point is user and system behaviors combined.

Use Case Testing: Explanation and Examples

Use case testing serves as a tool for deriving test cases. Let us review how it works via an example. Use cases can be represented as transaction lines (also called a model) and a diagram (visual depiction used to summarize user actions and system responses). We will focus on the use case model as it is more detailed.

From this basic use case, a QA specialist can create further test cases, e.g.:

• testing the availability of data input (can the user type in their name and password);
• testing the validation of login data (does the system validate the data if it is typed correctly or display an error);
• testing that the system grants access to the user account (is the account open to the user and is it their page), etc.

Use cases in software testing are often more complicated than the above option, as they can also contain:

• description – a brief account of the use case;
• pre-conditions – what should be included for successful completion (e.g., the system is online);
• triggers – causes of the use case start (e.g., an event/goal that prompted the user to act);
• basic flow – normal functioning of the system and logical/common actions from the user (so, it is the ‘success scenario’ mentioned in the table);
• alternate flow – also called an extension, describes possible paths branching out from the basic flow (e.g., if an actor inputs incorrect data then…);
• exception flow – a path that leads to non-completion (e.g., a user decides to close the page);
• post-conditions – what needs to be checked after the completion (e.g., the system displayed the ‘welcome’ message and redirected the user to their page).

A more comprehensive use case would look like this:

So, you can see how pretty much from each transaction in the above table a QA expert can create a test case.

How to Write Test Cases: a Comprehensive Guideline

How to Run a Use Case-Based Check

1. Review the use case document to make sure that each functional requirement is running and works as intended.
2. Ensure that each step of a use case is logical and represents a feasible user action. Also, ascertain that each step is actually testable.
3. Check the basic workflow by recreating the listed steps.
4. Do the same with alternate workflows to verify these paths are available and lead to predicted outcomes.
5. Go over each other workflow and note your results (obtained against expected).
6. Based on the above, test cases can be created later. For this, you would need to determine all possible test cases and test data needed to execute them.

Benefits and Implementations of Use Case Testing

Being within the black box testing category, use case testing capitalizes on inputs and outputs. So, you do not have to possess concrete knowledge of inner software processes. Thus, use cases help to:

• determine system complexity via the list of all achievable goals;
• define system needs by emphasizing the user and the system;
• comprehend system functionality due to their format;
• create extended use cases (also called epics) and predict potential issues;
• define all possibilities for the user and system limits;
• optimize system design by focusing on what the system can do;
• write use case-based test cases, which saves resources and time;
• develop quality software for the user (as use cases are user-centric).

In short, use case testing as a simple and efficient way to check system functionality. Even with its straightforward approach, use case testing has an impressive range of merits. Also, it is a great training tool for Junior QA agents.

5 Test Design Techniques QA Engineers Should Know

To Sum Up

Use cases can challenge our imagination. But it is good practice when you want to perfect your testing skills. By diving into the mind of a user, understanding their needs, and finding paths to satisfying them, you can deepen your QA knowledge. This will come in handy as you grow professionally. As you will be able to predict user actions, common functional flows, and thus, potential defects. With this, you will become an asset to any QA company.

Good luck, and keep learning.