Use case testing

Make a list of the different things you use software for every day.

Your list probably includes things like ‘post a photo on social media’, ‘set an alarm for tomorrow morning’, or ‘order a takeaway pizza’. Each of these will have been predicted as a use case, which aims to tell the story of what you do when you use the software.

But for a developer or tester, your understanding needs to be deeper than this, so let’s outline a clearer definition of use cases and see how they relate to testing.

What is a use case?

A use case is a list of the actions and events that make up the interactions between a system and those who use it. When we talk about use cases, we frequently refer to actors and subjects:

• An actor is a user type or another system that interacts with the system under testing.
• A subject is the component or system which the use case is applied to.

A use case gives us the functional requirements of the system from the perspective of the actor, conveying how they will use it to achieve their goal.

For example, the user (or actor) of an online shopping system wants to buy something and arrange for it to be delivered to their home. This activity involves more actors than just the customer, and the system (subject) will have several components. We can represent this kind of use case in a diagram like the one below:

To write the use case we look at the interactions that take place when someone uses the system. This gives us a sequence of actions in a dialogue between an actor and a component or system, with a tangible result.

A use case doesn’t only describe interactions and activities, it can include pre-conditions, post-conditions, and natural language, where appropriate. Interactions may be represented by graphical workflows, activity diagrams, or business process models. Here’s an example of a workflow:

Use case example main flow

‘Create Policy’ use case:

1. Use selects ‘Create Policy’ from the ‘Maintain Policies’ menu.
2. The system displays a Quote ID input field.
3. User enters a valid Quote ID.
4. The system displays the quote details (name, address, customer ID, policy type, term, cost).
5. User checks the details, enters the start date, and clicks on ‘Setup DD’ button.
6. The system displays the ‘Create Direct Debit’ screen.
7. User enters the customer’s bank details and premium collection amount and clocks on ‘Setup’.
8. The system generates the policy and displays ‘Policy No XXXXX created’.

Use cases are a natural test basis because it’s very easy to create tests from them. You can even devise a use case that looks for exceptions and error handling, allowing you to test what happens when something goes wrong or a user acts in an unexpected way.

Next, you will be introduced to white-box test techniques.