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 Enterusername
Enter Password
2 Validate Username and Password
3 Allow access to System
Extensions 1a InvalidUsername
System shows an error message
2b InvalidPassword
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.
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.

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.
 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
AActor/ 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 InvalidStudentID
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 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.

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.