Use Cases & User Stories: An Overview

Use Cases & User Stories

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

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 Copyright © by QA InfoTech. All rights reserved.

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. Copyright ÂŠ by QA InfoTech. All rights reserved.

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 Copyright © by QA InfoTech. All rights reserved.

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.

●

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.

●

Thank You

info@qainfotech.com www.qainfotech.com

Turn static files into dynamic content formats.

Create a flipbook