Use Cases & User Stories: An Overview

Agenda
● Use Cases
● Objectives of Use Cases
● Components of Use Cases
● How to create test cases from Use Cases
● Limitations
● User stories
● Difference between User Story and Use Case
● Benefits of a User story
Copyright © by QA InfoTech.
All rights reserved.

Use Cases
UML- UML (Unified Modeling Language) is a modeling language or graphical/diagrammatic notation for
object-oriented programming – a way to express the “blueprints” of your system.
USE CASE-
● Sequence of actions performed by a system
● It is a comprehensive description of a task or a series of tasks that users will accomplish using the software,
and includes the responses of the software to user actions.
Role of QA-
● Review Use Cases
● Document any query in Review Comment Form
● Repeat process till use cases are baseline
● Write SBTs

The superset of a use case is a requirement document which defines the business needs for a
project whereas a use case is typically a specific statement implied or derived from the requirement.
A requirement may map to multiple use cases.
Actor and Scenarios
An actor:
➔ A person, a system or some external entity linked to one or more system use cases
➔ Has a goal in using the system
A Use Case is Started By an Actor
Goal:
➔ What the actor wants to achieve by interacting with the system

Showing different services for different users and few common services for different users.
Access level of an application varies upon the change in the Role of an Actor.

Objectives of Use Cases
● To document the requirements of the proposed system in an easy to read, easy to track text
format.
● Serves as an effective communication tool.
● To document the business process that is to be supported by the system under development.
● To identify business decisions, actions and constraints.
● Represents the goal of an interaction between an actor and the system.
● Records a set of paths (flow of events) that traverse an actor from a trigger event (start of the
use case) to the goal (success scenarios).
● Records a set of scenarios that traverse an actor from a trigger event toward a goal but fall
short of the goal (failure scenarios).

Components of Use Cases
● Use Case Name
● Use Case Number
● Version
● Summary
● Associations/Dependencies
● Actors
● Stakeholders
● Business Rules & Constraints
● Pre-Conditions
● Triggers
● Flow of Events
● Post Conditions
● Associated Use Cases

How to create test cases from Use Cases
● The basic flow is a straight line down, while alternative flows are usually the loops going either back or forth.
● Before creating a test case, you need to identify all the scenarios for the given use case. A scenario is an
instance of the use case. It describes one specific path through the flow of events.
● The figure below is a hypothetical graph representing a use case with a basic flow B and alternative flows A1,
A2, A3, and A4. To find all scenarios, we need to draw all possible lines (Test Case) through this graph as
shown-

Limitations
● Use case flows are not well suited to non-functional requirements (like platform, performance,
timing, or safety-critical aspects).
● Use case templates do not ensure how clearly the application will interact with the user (as
clarity depends on the skill of the writer).
● As there is no standard definition of use case, each group (testers, end users and developer)
needs to interpret use cases correctly. Some of the relations could be ambiguous in
interpretation and can be difficult for stakeholders to understand.
● Agile methodology/Extreme Programming supporters often consider use cases as needlessly
document-centric, preferring to use the simpler approach of a user story.
● Use case developers often find it difficult to determine the level of UI dependency to incorporate
in a use case.

User stories
User stories are short, simple description of a feature told from the perspective of the person who desires the
new capability, usually a user or customer of the system.
They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>.
User stories are often written to facilitate planning and discussion. As such, they strongly shift the focus from writing
about features to discussing them. In fact, these discussions are more important than whatever text is written.

Difference between User story and Use case
The biggest differences between a User Story and a Use Case are:
A user story is a lightweight document that can be written on a card (“In order to”, “as a”, “I want”).
A user story doesn't capture all the details, it's an informal support for the discussion.
A use case is an heavyweight document that needs a word document format. It describes a
"Normal Flow" of steps and/or actions and "Alternative Flows" which are detailed. A use case
captures all the details, it's a formal specification.

Benefits of a User story
User stories are a quick way of handling customer requirements without having to create formalized requirement
documents and without performing administrative tasks related to maintaining them.
● Being very short. They represent small chunks of business value that can be implemented in a period of days
to weeks.
● Allowing developer and the client representative to discuss requirements throughout the project lifetime.
● Needing very little maintenance.
● Only being considered at the time of use.
● Allowing projects to be broken into small increments.
● Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery
drive the refinement process.
● Making it easier to estimate the development effort.

Thank You
info@qainfotech.com
www.qainfotech.com

Use Cases & User Stories: An Overview

More Related Content

What's hot

Similar to Use Cases & User Stories: An Overview

More from QA InfoTech

Recently uploaded

Use Cases & User Stories: An Overview