using stories to test requirements and systems

Using Business Stories to

Test Requirements and Systems

Paul [email protected]

Twitter: @paul_gerrard

Web: gerrardconsulting.com

Slide 1Intelligent Testing, Improvement and Assurance

mailto:[email protected]

http://testaxioms.com/?q=node/25

Who are You?

Agile, Structured or „Hybrid‟

Analysts, Testers or Developers

(Pick any 2, 3, 4, 5, or all 6)

Intelligent Testing, Improvement and Assurance Slide 2


This session is

for…Business Analysts in

Structured Projects

Test Analysts in

Structured Projects

Testers in

Agile Projects

Developers in

Agile Projects

What we‟ll

explore…Relationship of Stories

to Requirements

How Stories can test

Requirements

How Stories fit Agile

and Structured

How Stories spawn

manual/automated tests

We‟re going to examine how we can elicit and refine

requirements that are testable and viable for development

and capture requirements knowledge in a useful way.

Anyone who writes/reads requirements

or tests

What are Stories?

From Caveman, through Agile to

Mainstream

Agile story cards

Slide 6

From cave paintings to story cards… progress?

How stories can help

• People are very good at reasoning from even quite short stories to identify (for example):

– Omissions

– Inconsistencies

– Ambiguity

• These innate human capabilities give stories their power

• Stories are applicable to systems of all types, at any stage for different purposes.

Slide 8

A trigger for a conversation

• A story could be a few

words stuck on a post-it

note or index card

• Simplest definition:

– “A trigger for a conversation”

• But post-it notes (many tools

just simulate them) aren‟t

good requirements

repositories

• We need something better.

Slide 9

Story HeaderFeature: ship orders

As a orders clerk

I want to acknowledge and ship the order

So that we fulfil a book order

Scenario: ship a single book from stock

Given I select a valid order

And the ordered book is in stock

When I choose „acknowledge and ship‟

Then order status is changed to „shipped‟

And an address label is printed

Structured stories (other variations exist)

Slide 10

Key word

Story text

Each Story has multiple Scenarios

Scenarios can be data driven

Anatomy of a business story

headerFeature A label for the FACILITY a user needs to support

their business objective

As a… The ROLE of the user who needs to achieve the goal

I want (to)… The TASK the user wants to perform with the help of the system

So that… The GOAL of the user

Intelligent Testing, Improvement and

AssuranceSlide 11

• Note that roles can sometimes vary, but it is often better to reference „personas‟ that have multiple roles.

• Personas could be “18 year old male gamer” or “65 year old female retired nursery school teacher” for

example.

• The story brings together these aspects so we can view the feature from

different viewpoint to explore it

Anatomy of a scenario

Given… Pre-conditions that define the state of the system or scenario when the user performs the task

When… The values, inputs, commands or actions executed by the user to complete the task

Then… The outcome of the task (given the preconditions and the user inputs, actions etc.)


AssuranceSlide 12

• The parallel with test cases is obvious:

• given=precondition(s), when=steps, then=outcome(s)

• A scenario maps directly to a test case – but we haven‟t used the

word test yet.

• If I do – stop me.

Stories may have many scenarios

Slide 13

Feature: Ship an Order

In order to fulfil a book order

As a orders clerk

I want to acknowledge and ship the order

Scenario: ship a single book from stock


And the ordered book is in stock

When I choose „acknowledge and ship‟

Then order status is changed to „shipped‟

And an address label is printed

Scenario: advise a book is out of stock


And the ordered book is out of stock

When I choose „message the purchaser‟

Then Enter message to purchaser advising the order status

And an email is sent to the purchasers email address

Scenario: advise an item is discontinued


And the ordered book is discontinued

Etc. etc.

The View from Above 1

Agile Methods are Evolving

There‟s lots of them

Expect consolidation

Overview

• Countless new approaches emerging out of

the Agile community

• There seems to be a natural evolution

towards „Specification by Example‟

• Looks terrific in theory, and a few companies

appear to have it working

• But first some background…

Slide 16

Emerging Approaches

• We seem to be in the middle of an explosion of new approaches

– Mostly Agile but not exclusively so

– Some new but many rework established ideas

• Lean, Kanban and anything oriental in vogue

– Emerging management methods

• Acceptance-, Behaviour-, Design-, Test-Driven Development…

– Emerging specification and development methods

Slide 17

Wikipedia Search:

„driven development‟• Test-Driven

Development*

• Feature Driven Development *

• Behavior Driven Development *

• Tester Driven Development

• Business-Driven Development *

• Community Driven Development *

• Design-Driven Development

• Process Driven Development

• Test-Driven Development by Example *

• Model-Driven development *

• Event Driven Development *

• Goal-Driven Software Development Process *

Slide 18

„Variations on

a theme‟?

* Entries updated less than six months ago

Prescriptive v adaptive

Slide 19

Extracted from:

http://www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf

Regular Timeboxes

Event-Driven

Waterfall

Feedback loops (NOT to scale)

Slide 20

Unit Test

Pair Programming

Sprint

Daily Scrum

Continuous Integration

2-4 weekly

Daily

Hourly

Minutes

Seconds

Feedback ranges from personal observations (pairing), through

automated unit, build/integration tests, user tests and team retrospectives

From Test-Driven to Specification

by Example

…in 5 minutes

Test-Driven – from stories to code

Slide 22

The Story The Test The SoftwareThe Test code is

crafted by hand

Stories are not

(usually) retained

Behaviour-Driven – structured

story to code using today‟s tools

Slide 23


generated by a tool

from the stories

The stories are

captured as plain

text, code or html

Spec-by-Example – flowdown from

requirements to code

Slide 24


generated by the

SAME tool from

stories

The story is

captured in the

SAME tool as

requirements

The stories are

used to validate

requirements

Test code generation

• In the previous slides, I‟ve used the generation of xUnit (in this case, Python unit test) code to illustrate the story => test code process

• Test code could be the plain text, html or pseudocode used by existing BDD tools

– Developers don‟t need to change their ways

– Test code directly into version control means they can‟t tinker with it

• This stage is the natural interface from users and testers to (e.g. offshored) developers.

Slide 25

The View from Above 2

Structured folk want the best of Agile

Stories provide a natural link

Expect to see hybrid methods, new

toolsets emerge

Stories and the range of development

approaches

Slide 27

Waterfall/Structured

Agile

Where Stories Are Meaningful

‘Pure’ Agile

High Structure/Formality

• A one-dimensional view of the range of approaches• Varying formality, but ALL require discipline• But stories are universal as examples of features in use• Stories won‟t work where they are regarded as

„throwaway‟ in Agile projects (or anywhere)

No

man’s

land

Process Formality

“We’re not structured, let’s go Agile” Aaarghhh!


Assurance

Customer Domain

Supplier Domain

Stories and Structured Projects

RequirementsStories derived from written

requirements can be used to walk-

through business scenarios and when

users see the proposed system ‘in

action', requirements anomalies stand

out and trigger informed discussions

of situations, variations and

outcomes. A disciplined approach to

story-writing and…

StoriesStories derived

from requirements

Stories validate

requirements

Stories example

the rules

Dev O‟Lopper

Tests derived

from storiesAcceptance

Testers

Requirements

Define rules

+ Test Detailing

Stories generate

test code for TDD

• Developers using TDD can use business stories as a ‘starter for 10’

• Coverage of Business Stories is a necessary, but not sufficient, contractual requirement

How stories will help

• Stories instantiate features of the system and example them

• Stories fed back to stakeholders to validate requirements

• Requirements PLUS stories provide a better foundation for developers (less wriggle room)

• Stories provide logical tests for acceptance; testers can add detail and procedure, if necessary

• Stories can generate BDD (e.g. Cucumber) scripts or TDD (xUnit) code

• Customer-Supplier contract supported by stories and tests– Improves stability of the requirements and the relationship

– Suppliers who rely on vague requirements and change requests for their business model wont like it though (tough!)


AssuranceSlide 29

Requirements Stories or

Stories Requirements?• Requirements are written for the benefit of IT

– Complete, concise, precise, consistent, unambiguous

– Or none of the above

• Users want to tell stories and provide examples– The analysts transform these into requirements for

the techies to work with

• But if stories are part of the process, the natural, iterative approach to requirements elicitation, analysis and validation fits nicely

• So… adopt an Agile approach to requirements in your structured process?


AssuranceSlide 30

At which point the analysts

say, “but we‟ve always

worked that way”

Stories support all

development methods


Ubiquitous Language

• An emerging discipline, coming from the „Domain-Driven Design‟ community

• To create a flexible, knowledge-rich design, calls for a versatile, shared team language

• Ubiquitous language is intended to be used in business, system designs and even code

• UL is beyond the scope of this session, but expect it to gain traction over the next few years.


AssuranceSlide 32

COBOL was meant to be a Common Business-Oriented Language in 1959

So we need a tool that will…

• Manage business definitions

• Index defined terms throughout requirements, stories and scenarios

• Capture requirements and story detail, and cross-refer them

• Output requirement and story content in an easy-to-review format

• Output BDD/TDD code for use by developers.


AssuranceSlide 33

How to Test Requirements with

Stories


Example requirement: what needs

definition?1. A customer order will have a unique order

reference a customer identifier, an order

date and a required-by date.

2. Each order generates multiple order items

each of which has a unique ID, a product

identifier, an order quantity, a unit

price, a unit weight, a promised delivery

date and required-by date.

3. The total order price, earliest and

latest delivery date, total weight will

be calculated from the items on the

order.


AssuranceSlide 35

As a tester; as a developer

Example requirement: what needs

definition?1. A customer order will have a unique order

reference a customer identifier, an order

date and a required-by date.

2. Each order generates multiple order items

each of which has a unique ID, a product

identifier, an order quantity, a unit

price, a unit weight, a promised delivery

date and required-by date.

3. The total order price, earliest and

latest delivery date, total weight will

be calculated from the items on the

order.


AssuranceSlide 36

What other questions might you

ask?1. „customer order will have…‟ means what?

2. „unique order reference‟ unique in what context?

3. „Order date‟: date placed, or date recorded or other date to be defined?

4. „Each order generates‟ – means what?

5. Can an order have zero items? Is there a limit to how many items?

6. Can order quantity be negative, non-zero, is it a decimal or integer?

7. Must dates be weekdays or can they be weekends? Are there any date rules to apply?

8. What currency are prices in?

9. What units is weight measured in?

10. Is deliver-date the last required-by date or is it calculated some other way?

11. Other definitions? „Customer‟, „required-by‟, „weight‟, „unit‟, „promised‟, „total (price)‟, „product‟

12. Where do these pieces of data come from? Where are they stored? Where do they „go to?


AssuranceSlide 37

Typical questions to ask of a

requirement• What do the nouns and verbs actually mean?

• What features are being described here?

• What outcomes do these features provide?

• What scenarios (normal, extreme, edge and exceptional) should they cope with?

• Are all outcomes predictable from the text?

• Are all outcomes unambiguous?

• Is anything (definitions, features, scenarios or outcomes) missing?


AssuranceSlide 38

Definition

Feature

Outcome

Scenarios

Prediction

Missing

Ambiguity

D e F O S P A M

• Definitions

• Features

• Outcomes

• Scenarios

• Prediction

• Ambiguity

• Missing


AssuranceSlide 39

Identify the terms

One story per feature

One scenario per outcome

One scenario per scenario

Can‟t predict? Scenario + guess outcome

Two stories with conflicts

Add a story as a suggestion

See Handout

Creating Stories

I have a 12-page „User Story

Guideline‟ that might help.

Email me and I‟ll send you a copy.

D e F O S P A M – Exercise 0

• Definitions

• Features

• Outcomes

• Scenarios

• Prediction

• Ambiguity

• Missing


AssuranceSlide 41

• The calculator will accept three inputs: a

number A, an operator O and another

number, B.

• The calculator will validate the numbers A

and B as valid in the range -1000,000,000

to +1000,000,000

• The operator may be one of the following:

"+" (plus), "-" (minus), "*" (multiply) or "/"

(divide)

• The calculator will perform the calculation

according to standard arithmetical rules

• The calculator will print the result as a

real number with up to 20 significant

digits.

Using Testela

Accessing Testela BETA

• Network: checkout the posters on the walls

• Accessing Testela through your browser

• Account details:

“[email protected]” password: “password”

nnn is 001–100 – I‟ll allocate numbers to you

• When you log in, click „edit profile‟ and change your details (and change password too perhaps)


AssuranceSlide 43

Features we‟ll use today

• Requirements

• Stories

• Scenarios

• Dictionary

• Export Feature/Scenarios

• Export Unit Tests


AssuranceSlide 44

Exercise 1: Adding your first story

• Product tab-> Click „Add Story‟

– Select requirement, role, leave „assigned to‟ as is

– Submit

• Click „Find Stories‟ and user filter to find your

story

• Click „Add a scenario‟ – confirm it

• Click „View All Story Scenarios‟


AssuranceSlide 45

The Dictionary

• The Dictionary allows you to capture definitions of terms in a glossary

• These definitions are indexed for requirements and stories

• Benefits

– Term, entity, concept… coverage

– Encourages ubiquitous language

– Tagging of content is not necessary

– Business impact analyses are possible.


AssuranceSlide 46

Using the dictionary

• What terms need definition?

• I‟ll add them to the glossary

– And re-index

• Now look at the requirement and your story

– Index listing at the bottom of page

• Go to Dictionary->Index

• Let‟s look at some of your stories and discuss


AssuranceSlide 47

Exercise 2: Requirement 207

• To access requirement enter r/207 in the fast

access field and press return

• This is a better requirement than before

• Add a story as before and we‟ll walk through

creating an examples table

• Let‟s add some glossary terms too


AssuranceSlide 48

Exercise 3: Requirement 206

• If we have time…

• To access requirement enter r/207 in the fast

access field and press return

• This is a better requirement than before

• Add a story as before and we‟ll walk through

creating an examples table

• Let‟s add some glossary terms too


AssuranceSlide 49

Exercise 4: Generate test scenarios

• Find one of your stories and view it

• Click on the „Lock Story‟ link

• Click „View Test Scenarios‟

• Click on „Edit‟ for one of them


AssuranceSlide 50

Demo Code Generation

Using Stories

• We can use stories to:– Illustrate features described by requirements in business

language

– Validate requirements by feeding back to users

– Generate acceptance test cases manual end to end tests

– Generate BDD script (e.g. Cucumber) or xUnit or (in principle) and automation framework code

• Stories plus a dictionary allows us to manage knowledge in a consistent way

• New coverage types, tagging/taxonomies and impact analyses are now possible

• Why haven‟t we always used stories?


AssuranceSlide 53


Want to evaluate Testela?

Do get in touch.

More info at: testela.com

Thanks once again

Using Business Stories to

Test Requirements and Systems

Paul [email protected]

Twitter: @paul_gerrard

Web: gerrardconsulting.com

Slide 55Intelligent Testing, Improvement and Assurance

mailto:[email protected]

http://testaxioms.com/?q=node/25

using stories to test requirements and systems

Technology