Use Cases & User Stories: An Overview

Views:
 
Category: Education
     
 

Presentation Description

Any software product cannot be developed if one does not know the "how" and the "why" of it. Via use cases and today, more specifically-user stories, understand this concept better through this PPT which will shed light on objectives, components, limitations and creation of test case from use cases, benefits of a user story, the difference between user story and use case and stay tuned for more!

Comments

Presentation Transcript

slide 1:

Use Cases User Stories

slide 2:

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.

slide 3:

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

slide 4:

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.

slide 5:

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.

slide 6:

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

slide 7:

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.

slide 8:

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

slide 9:

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

slide 10:

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

slide 11:

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 doesnt capture all the details its 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 its a formal specification. Copyright © by QA InfoTech. All rights reserved.

slide 12:

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

slide 13:

Thank You infoqainfotech.com www.qainfotech.com

authorStream Live Help