What is Use Case Testing?

Use Case Testing is a software testing technique that helps to identify test cases that cover entire system on
a transaction by transaction basis from start to end. Test cases are the interactions between users and
software application.

Use case testing helps to identify gaps in software application that might not be found by testing individual
software components.

A Use Case in Testing is a brief description of a particular use of the software application by an actor or
user. Use cases are made on the basis of user actions and the response of the software application to those
user actions. It is widely used in developing test cases at system or acceptance level.

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 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.
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.
Representation
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

Actors/Users 1 Enter username

Enter Password

2 Validate Username and Password

3 Allow access to System

Extensions 1a Invalid Username

 Use Case Name Login

System shows an error message

2b Invalid Password
System shows an error message

3c Invalid Password for 4 times

Application closed

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 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 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.

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 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.

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,s 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 successfully.

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 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 ‘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 ‘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
Pre-Condition:
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

A: Actor/ 1 Enter Student Name

S: System

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

 Test Cases Steps Expected Result

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
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 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 are any.
How to do Use Case Testing: Example
In a use-case, an actor is represented by “A” and system by “S”. We create Use for a login functionality of a
Web Application as shown below

Main Success Scenario Step Description

1 A: Enter Agent Name & Password
A:Actor
2 S: Validate Password
S:System
3 S: Allow Account Access
Password not valid
2a
S: Display Message and ask for re-try 4 times
Extensions
Password not valid 4 times
2b
S: Close Application

 Consider the first step of an end to end scenario for a login functionality for our web application
where the Actor enters email and password.
 In the next step, the system will validate the password
 Next, if the password is correct, the access will be granted
 There can be an extension of this use case. In case password is not valid system will display a
message and ask for re-try four times
 If Password, not valid four times system will ban the IP address.