Use Case and Use Case Testing Complete Tutorial

To start with, let’s understand ‘What is Use Case?’ and later we will discuss ‘What is Use Case Testing?’.

A use case is a tool for defining the required user interaction. If you are trying to create a new application or make changes to an existing application, several discussions are made. One of the critical discussions you have to make is how you will represent the requirement for the software solution. 

Business experts and developers must have a mutual understanding of the requirement, as it’s very difficult to attain. Any standard method for structuring the communication between them will be a boon. It will, in turn, reduce the miscommunications, and here is the place where the Use case comes into the picture.

This tutorial will give you a clear picture of the concept of Use case and testing, thereby covering the various aspects involved it with practical examples for easy understanding of anyone who is completely new to the concept.

Use Case

Use case plays a significant role in the distinct phases of the Software Development Life Cycle. Use Case depends on ‘User Actions’ and ‘Response of System’ to the User Actions.

It is the documentation of the ‘Actions’ performed by the Actor/User and the corresponding ‘Behaviour’ of the System to the User ‘Actions’. Use Cases may or may not result in achieving a goal by the ‘Actor/User’ on interactions with the system.

In Use Case, we will describe ‘How a System will respond to a given Scenario?’. It is ‘user-oriented’ not ‘system-oriented’.

It is ‘user-oriented’: We will specify ‘What are the actions done by the user?’ and ‘What do the Actors see in a system?’.

It is not ‘system-oriented’: We will not specify ‘What are the inputs given to the system?’ and ‘What are the outputs produced by the system?’.

The development team needs to write the ‘Use Cases’, as the development phase highly depends on them.

Use case writer, Team members, and the Customers will contribute towards the creation of these cases. For creating these, we need to have a development team assembled and the team should be highly aware of the project concepts.

After implementing the case, the document is tested, and the behavior of the System is checked accordingly. In this case, the capital Letter ‘A’ denotes ‘Actor’, and the letter ‘S’ denotes ‘System’.

Who uses ‘Use Case’ documents?

This documentation gives a complete overview of the distinct ways in which the user interacts with a system to achieve the goal. Better documentation can help to identify the requirements for a software system in a much easier way.

This documentation can be used by Software developers, software testers as well as Stakeholders.

Uses of the Documents:

• Developers use the documents for implementing the code and designing it.
• Testers use them for creating the test cases.
• Business stakeholders use the document to understand the software requirements.

Types of Use Cases

There are 2 types.

They are:

• Sunny day
• Rainy day

#1) Sunny day Use Cases

They are the primary cases that are most likely to happen when everything goes well. These are given high priority than the other cases. Once we have completed the cases, we give them to the project team for review and ensure that we have covered all the required cases.

#2) Rainy Day Use Cases

These can be defined as the list of edge cases. The priority of such cases will come after the ‘Sunny Use Cases’.  We can seek the help of Stakeholders and product managers to prioritize the cases.

Elements in Use Cases

Given below are the various elements:

1) Brief description: A brief description explaining the case.

2) Actor: Users that are involved in Use Cases Actions.

3) Precondition: Conditions to be Satisfied before the case begins.

4) Basic Flow: ‘Basic Flow’ or ‘Main Scenario’ is the normal workflow in the system. It is the flow of transactions done by the Actors to accomplish their goals. When the actors interact with the system, as it’s the normal workflow, there won’t be any error and the Actors will get the expected output.

5) Alternate flow: Apart from the normal workflow, a system can also have an ‘Alternate workflow’. This is the less common interaction done by a user with the system.

6) Exception flow: The flow that prevents a user from achieving the goal.

7) Post Conditions: The conditions that need to be checked after the case is completed.

Representation

A case is often represented in plain text or a diagram. Due to the simplicity of the use case diagram, it is considered to be optional by any organization

Use Case Example:

Here I will explain the case for ‘Login’ to a ‘School Management System’.

Points to be noted

• Common mistakes that the participants do with Use Case is that either it contains too many details about a particular case or no enough details at all.
• These are textual models if required we may or may not add a visual diagram to it.
• Determine the applicable precondition.
• Write the process steps in the correct order.
• Specify quality requirements for the process.

How to Write a Use Case?

The points summarized below will help you to write these:

=> When we are trying to write a case, the first question that should be raised is ‘What’s the primary use for the customer?’ This question will make you write your cases from the User’s perspective.

=> We must have obtained a template for these.

=> It must be productive, simple, and strong. A strong Use Case can impress the audience even if they have minor mistakes.

=> We should number it.

=> We should write the Process Step in its Order.

=> Give a proper name to the Scenarios, naming must be done according to the purpose.

=> This is an iterative process, which means when you write them for the first time it won’t be perfect.

=> Identify the actors in the system. You may find a bunch of actors in the system.

For example, if you consider an e-commerce site like Amazon, there we can find actors like buyers, sellers, wholesale dealers, auditors, suppliers, distributors, customer care, etc.

Initially, let’s consider the first actors. We can have more than one actor having the same behavior.

For Example, both Buyer/Seller can ‘Create an Account’. Likewise, both ‘Buyer and Seller’ can ‘Search for Item’. So, these are duplicate behaviors and they need to be eliminated. Apart from using duplicate cases, we must have more general cases. Hence, we need to generalize the cases to avoid duplication.

=> We must determine the applicable precondition.

Use Case Diagram

Use Case Diagram is a pictorial representation of a user(s) Actions in a system. It does provide a great tool in this context, if the diagram contains a lot of actors, then it is very easy to understand. If it is a high-level diagram, it won’t share a lot of details. It shows complex ideas in a fairly basic way.

Fig No: UC 01

As shown in Fig No: UC 01 it represents a diagram where Rectangle represents a ‘System’, the oval represents a ‘Use Case’, Arrow represents a ‘Relationship’ and the Man represents a ‘User/Actor’. It shows a system/application, then it shows the organization/people who interact with it, and shows the basic flow of ‘What the system does?’

Fig No: UC 02

Fig No: UC 03 – Use case diagram for login

This is the Use case diagram of the ‘Login’ case. Here, we have more than one actor, they are all placed outside the system. Students, teachers, and parents are considered primary actors. That is why they all are placed on the left side of the rectangle.

Admin and Staff are considered secondary actors, so we place them on the right side of the rectangle. Actors can log in to the system, so we connect the actors and login cases with a connector.

Other functionality found in the system are Reset Password and Forgot Password. They are all related to log-in cases, so we connect them to the connector.

User Actions

These are the actions that are done by the user in a system.

For Example: Searching on-site, Adding an item to favorites, trying to contact, etc.

Note:

• A System is ‘whatever you are developing’. It can be a website, an app, or any other software component. It is generally represented by a rectangle. It Contains Use Cases. Users are placed outside the ‘rectangle’.
• Use Cases are generally represented by Oval shapes specifying the Actions inside them.
• Actors/Users are the people who use the system. But sometimes it can be other systems, people, or any other organization.

What is Use Case Testing?

It comes under the Functional Black Box testing technique. As it is black box testing, there won’t be any inspection of the codes. Several interesting facts about this are briefed in this section.

It ensures that the path used by the user is working as intended or not. It makes sure that the user can accomplish the task.

Some Facts

• It is not testing that is performed to decide the quality of the software.
• Even if it is a type of end-to-end testing, it won’t ensure the entire coverage of the user application.
• Based on the test result known from the Use Case testing we cannot decide on the deployment of the production environment.
• It will find out the defects in integration testing.

Use case Testing Example:

Consider a scenario where a user is buying an Item from an Online Shopping Site. The user will First log in to the system and start performing a Search. The user will select one or more items shown in the search results and he will add them to the cart.

After all this, he will check out. So this is an example of a logically connected series of steps that the user will perform in a system to accomplish the task.

The flow of transactions in the entire system from end to end is tested in this testing. Use Cases are generally the path that users are most likely to use, to achieve a specific task.

So, this makes Use Cases easy to find the defects as it includes the path that the users are more likely to come across when the user is using the application for the first time.

Step 1: The first step is the review of Use Case documents.

We need to review and make sure that the functional requirements are complete and correct.

Step 2: We need to make sure that Use Cases are atomic.

For Example: Consider a ‘School management System having many functionalities like ’Login’, ‘Show Student Details’, ‘Show Marks’, ‘Show Attendance’, ‘Contact Staff’, ‘Submit Fees’, etc. For this instance, we are trying to prepare the Use Cases for ‘Log in’ functionality.

We need to make sure that none of the normal workflow needs have to mix up with any other functionality. It must be totally related to the ‘Login’ functionality only.

Step 3: We need to inspect the normal workflow in the system.

After inspecting the workflow, we must ensure that it is complete. Based on the knowledge of the system or even domain, we can find out the missing steps in the workflow.

Step 4: Ensure that the alternate workflow in the system is complete.

Step 5: We should make sure that each step in the Use Case is testable.

Each step explained in the Use Case testing is testable.

For Example, some credit card transactions in the system are not testable due to security reasons.

Step 6: Once we have revived these cases, then we can write the test cases.

We must write test cases for each normal flow and alternate flow.

For Example, Consider the ‘Show Student Marks’ case, in a School Management System.

Use case Name: Show Student Marks

Actors: Students, Teachers, Parents

Pre-Condition:

1) The system must be connected to the network.

2) Actors must have a ‘Student ID’.

Use Case for ‘Show Student Marks’:

Corresponding Test Case for ‘Show Student Marks’ case:

Please note that the Test Case table shown here contains only the basic information. ‘How to create a Test Case template’ is explained in detail below.

The table displays the ‘Test Case’ corresponding to the ‘Show Student Mark’ case as shown above.

The best way to write test cases is to write the test cases for ‘the Main scenario’ first, and then write them for ‘Alternate Steps’. The ‘Steps’ in Test Cases are obtained from Use Case documents. The very first ‘Step’ of the ‘Show Student Mark’ case, ‘Enter Student Name’ will become the first Step in the ‘Test Case’.

The User/Actor must be able to enter it. This becomes the Expected Result.

We can seek the help of test design techniques like ‘boundary value analysis’, and ‘equivalence partitioning ‘while we prepare the test cases. The test design technique will help to reduce the number of test cases thereby reducing the time taken for testing.

How to Create a Test Case Template?

When we are preparing the test cases we must think and act like the end-user i.e. put yourself in the shoes of an end-user.

Several tools are available in the market to help in this context. ‘TestLodge’ is one among them, but it is not a free tool. We need to purchase it.

We need a template for documenting the Test Case. Let’s consider a common scenario, ‘FLIPKART login’ that we all are familiar with. Google spreadsheet can be used to create the test case table and share it with the team members. For the time being, I am using an Excel document.

Here is an Example

=> DOWNLOAD this test case table template here

First of all, name the test case sheet with an appropriate Name. We are writing test cases for a particular module in a project. So, we need to add the ‘Project Name’ and the ‘Project Module’ columns in the test case table. The document must include the name of the creator of the test cases.

Therefore add ‘Created by’ and ‘Created Date’ columns. The document must be reviewed by someone (Team leader, Project manager, etc), so add the ‘Reviewed by’ column and ‘Reviewed Date’.

The next column is ‘Test Scenario’, here we have provided the Example Test Scenario ‘Verify Facebook Login’. Add the columns ‘Test Scenario ID’ and ‘Test Case Description’.

For every Test Scenario, we will write ‘Test Cases’. So, add the columns ‘Test Case ID’ and ‘Test Case Description’. For every test Scenario, there will be ‘Post Condition’ and ‘Pre-Condition’. Add the columns ‘Post-Condition’ and ‘Pre-Condition’.

Another important column is ‘Test Data’. It will contain the data that we use for testing. A test scenario must assume an expected result and the actual result. Add the column ‘Expected Result’ and ‘Actual Result’. ‘Status’ shows the result of the test scenario execution. It can be either pass/fail.

Testers will execute the test cases. We need to include it as ‘Executed by’ and ‘Executed date’. We will add ’Commands’ if there are any.

Conclusion

I hope you would have got a clear idea about Use Cases and Use Case Testing.

Writing these cases is an iterative process. You just need a little practice and a good knowledge of a system to write these cases.

In a nutshell, we can use ‘Use Case testing’ in an application to find missing links, incomplete requirements, etc. Finding them and modifying the system will attain efficiency and accuracy to the system.

Do you have prior experience with use cases and testing? Feel free to share with us in the comments section below.