Use Case Testing with example

We discussed a couple of black box test design techniques such as BVA, equivalence partitioning etc in the previous blog posts. Today lets focus on another widely used test design technique known as Use Case Testing.

Before going into the test design details, it is good to have an understanding on use case itself.

What is a Use Case ?

In simple terms, it is a formal way of representing  how  a system interacts with its environment. Or in other words, it defines the activities that are performed by the users (actors) of a system to achieve certain goals.

Actors can be human or external system.

Hence use case testing is defined as a black-box test design technique in which test cases are designed to execute scenarios of use cases.

In order to understand this in detail, lets look into a familiar use case of Login Functionality.

use case testing scenarios

                                                                                                     use case testing scenarios

As represented in the figure, the login use case can have different behaviors. Generally use cases have both happy path (or Main path/Typical Path) and Alternate path. These terms even referred as ‘sunny day scenarios’ and ‘rainy day scenarios’ .

Happy path represents the typical sequence of user actions and system responses. (E.g. Successful login attempt)

However Alternate path represents errors, exceptions and less typical usage paths.(E.g: Invalid username/password combinations)

When it comes to testing, minimum coverage of a use case is to have one test case for main path and one test case for each alternative path. 

Coverage percentage = No of Paths tested / total number of main and alternate paths

Applicable testing levels for Use Case Testing

  • System testing
  • Acceptance testing
  • Performance testing

The main advantage of use case testing is that it helps testers addressing the customer’s need. Because the basis for this testing is the use cases, which is nothing but the real transactions users performing. This can sometimes turns into the major weakness of this technique too. In those cases use cases may not reflect the actual usage scenarios.

In test design technique series, so far we have covered various black box test case design techniques. First, we have covered equivalence partitioning, boundary value analysis, and decision tables(which are best in transaction testing situations). Next, we looked at state-based testing, which is ideal when we have sequences of events that occur and conditions that apply to those events. In this article, we  covered use cases, which helps to insulate various workflows. With these  techniques in hand, you have a set of powerful techniques for testing the business logic of a system.

Next series of posts, we will be concentrating more on  various white box design techniques.

Stay Tuned!!