creating test scenarios

8/3/2019 Creating Test Scenarios

1/18

Creating Test Scenarios and Test cases


2/18

OVERVIEW

In this session, we will discuss about:

Use cases

Scenarios

Characteristics of ideal scenario tests Why we use scenario tests?

How to create good scenarios?

Test cases

Example

Traceability Matrix


3/18

USE CASES

An individual use case consists of:

Preconditions, which set the series of events that should occur for

the use case to be executed

Results, which state the expected outcomes of the above process

Sequential steps to execute the use case

The information that needs to be specified for each usecase: Use Case Name or ID

Short phrase in business terms or identifier that identifies anddescribes the use case.

Actor Anything that needs to exchange information with the system.Often

it is a role played by the user


4/18

USE CASE (CONTD..)

Objective A description of use case with defined set of conditions.

Preconditions The entrance criteria or state that the system must be in for the

execution of use case.

Results The expected completion criteria of the use case.

Detailed Description

The sequence of steps (performed by the actor) necessary to

execute the use case.

The model (system) response of each step. This is the basic course of events that support the precondition and

results.

The description is from a users (black-box) point of view and

does not include details about the events of the internal system.


5/18

USE CASE (CONTD..)

Exceptions

Errors or deviations that may occur during the execution of test

case that cause the actor to deviate from the basic course.

Alternative Courses

A deviation from the step-by-step event so that the DetailedDescription can be modified as these events generally inserts

extra steps or omits some steps from the detailed Description.

These are valid events, but are not the basic course of events.


6/18

SCENARIOS

Test Scenario is a high level test case that is generally

derived from use case

A test scenario is almost like a story

Example:Suppose we have a site of payroll, then a valid scenario can

be:

A user enters into the application from login window by

entering valid user name and password. After enteringuser will click on module payslip and clicks on latest payslip

feature to view latest payslip.


7/18

SCENARIOS (CONTD..)

The information that needs to be specified for eachscenario

Scenario ID

Short phrase in business terms or identifier that identifies and

describes the use case Use Case Name or ID

Mention the use case id of a use case from which the scenario isderived

Objective

One liner or multiple line of description of what user is going to test

for a specific use case with defined set of conditions


8/18

CHARACTERISTICSOFIDEAL SCENARIO TESTS

The scenario test should be based on the story of a real worldwhere the program is used, including information about themotivations of the people involved in the program use.

The scenario test should be motivating in the sense that a

stakeholder with influence (who can influence developmentdecisions ), if convinced with the scenario can push to fix aprogram that failed the scenario test.

The scenario test should be credible in the sense that it makes thestakeholders believe that not only it could happen in the real

world but something like it probably will happen.


9/18

CHARACTERISTICSOFIDEAL SCENARIO TESTS (CONTD..)

The scenario test should involve a complex use of the program or

a complex environment or a complex set of data.


10/18

WHY USE SCENARIOS TESTS?

Early in testing, scenarios can be used to learn the product.

Scenarios are also useful to connect to documented software

requirements, especially requirements modeled with use cases.

You can use scenarios to expose failures to deliver desiredbenefits.

Scenarios are also useful for exploring expert use of a program.

Scenarios are especially interesting for surfacing requirements-

related controversies.


11/18

HOW TO CREATE GOOD SCENARIOS?

Write life histories for objects in the system.

List possible users, analyze their interests and objectives.

Consider disfavored users: how do they want to abuse yoursystem?

List system events. How does the system handle them? List special events.What accommodations does the system

make for these?

List benefits and create end-to-end tasks to check them.

Check product forums where users have described about famous

challenges and failures of the old system.


12/18

HOW TO CREATE GOOD SCENARIOS? (CONTD..)

Study already reported issues from users to see how they workand what they do.

Read about similar systems available in the market to see whatsystems like this are supposed to do.

Study complaints about the predecessor to this system or itscompetitors.

Create a mock business. Treat it as real and process its data.

Try converting real-life data from a competing or predecessorapplication.


13/18

TEST CASE

How to develop test case?

A test case is a set of test inputs, execution conditions, and expected

results developed for a particular test objective.

There should be a one-to-one relationship between test scenario

definitions and test cases.

Though, there can be numerous test cases for each scenario, there needs

to be at least two test cases for each scenario: one for successful execution

of the scenario and the other for an unsuccessful execution of a scenario.


14/18

TEST CASES (CONTD..)

Format of Test Cases

Test Case ID

A unique identifier for this particular test case. This is based on company

standard.

Scenario ID This should map with parent scenario ID from the scenario list

Test Objective

Summary of the test case i.e. what user is going to test.

Precondition

Define the entrance criteria of the test case that is required to execute test

case

Procedure (steps to execute)

The detailed steps that the executor follow to execute the test case.


15/18

TEST CASES (CONTD.. )

Expected Result Out come of the test case

Input Data The input that is necessary in order for the test case to be executed.

Status

This field should filled after the test case is executed i.e. Pass/Failed Comment

Guidance from the actor to individual who will actually perform the test.


16/18

TEST CASE (CONTD..)

Tips on writing a good test case

Pretend you're writing a bug - it's pretty much the same

Assume that the person following your test case only has basic familiaritywith the product. For example:

"Bring up the New Calendar Wizard"- This is too vague. "Launch the New Calendar Dialog (by either double clicking calendar list, File-

>New Calendar or right clicking calendar list)."- This is much better.

Be fairly specific with the expected results

"It worked"- Once again, too vague.

The Calendar is opened "- This is great.


17/18

TEST CASE (CONTD.. )

Keep list of steps and expected results as simple as possible.

You don't need to detail every click unless it's an important part of the testcase.


18/18

creating test scenarios

Documents