Sir Syed University of Engineering & Technology, Karachi

CS-470
Software Quality Assurance & Testing
Week 9
Session 2

Batch - 2017 Department of Computer Science 1

 Use cases
• 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’.
• 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’.

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

3
 Types of Use cases
• There are 2 types.
– Sunny day
– Rainy day
– 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.

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

4
 Use case Testing ...
• Use cases are one way of specifying functionality as business scenarios or process
flows.
• They capture the individual interactions between ‘actors’ and the system.
• An actor represents a particular type of user and the use cases capture the
interactions that each user takes part in to produce some output that is of value.
• Test cases based on use cases at the business process level, often called scenarios,
are particularly useful in exercising business rules or process flows and will often
identify gaps or weaknesses in these that would not be found by exercising
individual components in isolation.
• This makes use case testing very effective in defining acceptance tests because the
use cases represent actual likely use.

5
 ... Use case Testing
• Use cases may also be defined at the system level, with preconditions that define
the state the system needs to be in on entry to a use case to enable the use case
to complete successfully, and post conditions that define the state of the system
on completion of the use case.
• Use cases typically have a mainstream path, defining the expected behaviour, and
one or more alternative paths related to such aspects as error conditions. Well
defined use cases can therefore be an excellent basis for system level testing, and
they can also help to uncover integration defects caused by incorrect interaction or
communication between components.
• In practice, writing a test case to represent each use case is often a good starting
point for testing, and use case testing can be combined with other specification
based testing.

6
 Use case example 1
• In a use case diagram each type of user is known as an actor, and an actor stands
for all users of the type. Use cases are activities carried out for that actor by the
system.
• This is, in effect, a high-level view of requirements.
• The diagram alone does not provide enough detail for testing, so we need some
textual description of the processes involved as well.
• Use case testing has the major benefit that it relates to real user processes, so it
offers an opportunity to exercise a complete process flow.
• The principles applied elsewhere can be applied here: first test the highest priority
(highest value) use cases by taking typical examples; then exercise some attempts
at incorrect process flows; and then exercise the boundaries.

7
 Use case example 2
• System requirements can also be specified as a set of use cases.
• This approach can make it easier to involve the users in the requirements
gathering and definition process.
• ATM cash withdrawal:

8
Use case example 3

9
 Use case of a School Login System

• 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.
10
 School management System 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.

11
 School management System Example
• 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.
• 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.

12
 School management System Example
• 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’.

13
School management System Example - Use Case for
‘Show Student Marks’:

14
School management System Example - Corresponding
Test Case for ‘Show Student Marks’ case:

15
 School management System Example - 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 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.

16