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 discussion you have to make is how you will represent the requirement for the software solution.
Business experts and developers must have a mutual understanding about the requirement, as it’s very difficult to attain. Any standard method for structuring the communication between them will really be a boon. It will, in turn, reduce the miscommunications and here is the place where Use case comes into the picture.
This tutorial will give you a clear picture about 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.
What You Will Learn:
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 the Actors see in a system?’.
It is not ‘system-oriented’: We will not specify ‘What are the input given to the system?’ and ‘What are the output 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 a case the capital Letter ‘A’ denotes ‘Actor’, 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 requirement 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 for understanding the software requirements.
Types of Use Cases
There are 2 types.
- Sunny day
- Rainy day
#1) Sunny day Use Cases
They are the primary cases that are most likely to happen when everything does well. These are given high priority than the other cases. Once we have completed the cases, we give it 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 on accomplishing 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.
A case is often represented in a 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’.
|Use Case Name||Login|
|Use case Description||A user login to System to access the functionality of the system.|
|Actors||Parents, Students, Teacher, Admin|
|Pre-Condition||System must be connected to the network.|
|Post -Condition||After a successful login a notification mail is sent to the User mail id|
|Main Scenarios||Serial No||Steps|
|2||Validate Username and Password|
|3||Allow access to System|
System shows an error message
System shows an error message
|3c||Invalid Password for 4 times
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 requirement 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 raise 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 the 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 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.
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 the 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 is containing 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 the Fig No: UC 01 it represents a diagram where Rectangle represents a ‘System’, oval represent 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 ‘Login’ case. Here, we have more than one actor, they are all placed outside the system. Students, teachers, and parents are considered as primary actors. That is why they all are placed on the left side of the rectangle.
Admin and Staff are considered as 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 case with a connector.
Other functionality found in the system are Reset Password and Forgot password. They are all related to login case, so we connect them to the connector.
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.
- 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 it.
- Actors/Users are the people who use the system. But sometimes it can be other systems, person or any other organization.
What is Use Case Testing?
It comes under the Functional Black Box testing technique. As it is a black box testing, there won’t be any inspection of the codes. Several interesting facts about this are briefed in this section.
It ensures if the path used by the user is working as intended or not. It makes sure that the user can accomplish the task successfully.
- 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 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 Login 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 logically connected series of steps which 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, in order 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 ‘Login’ 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 ‘Log in’ 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 if 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
1) The system must be connected to the network.
2) Actors must have a ‘Student ID’.
Use Case for ‘Show Student Marks’:
|Main Scenario||Serial Number||Steps|
|1||Enter Student Name|
|2||System Validates Student Name|
|3||Enter Student ID|
|4||System Validates Student ID|
|5||System shows Student Marks|
|Extensions||3a||Invalid Student ID
S: Shows an error message
|3b||Invalid Student ID entered 4 times.
S: Application Closes
Corresponding Test Case for ‘Show Student Marks’ case:
|Test Cases||Steps||Expected Result|
|A||View Student Mark List 1 -Normal Flow|
|1||Enter Student Name||User can enter Student name|
|2||Enter Student ID||User can enter Student ID|
|3||Click on View Mark||System displays Student Marks|
|B||View Student Mark List 2-Invalid ID|
|1||Repeat steps 1 and 2 of View Student Mark List 1|
|2||Enter Student ID||System displays Error message|
Please note that the Test Case table shown here contains only the basic information. ‘How to create 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 got from Use Case documents. The very first ‘Step’ of ‘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 technique like ‘boundary value analysis’, ‘equivalence partitioning ‘while we preparing the test cases. The test design technique will help to reduce the number of test cases and 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.
There are several tools that 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 time being, I am using an Excel document.
Here is an Example
Frist 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 ‘Reviewed by’ column and ‘Reviewed Date’.
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 each and 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 which 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 is any.
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 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 the missing links, incomplete requirements, etc. Finding them and modifying the system will attain efficiency and accuracy to the system.
Do you have prior experiences with use cases and testing? Feel free to share with us in the comments section below.