its testing-jim-but-not-as-we-know-it-devoxx

@YourTwitterHandle#YourSessionHashtag

It’s testing, Jim, but not as we know it

John Ferguson Smart @wakaleo https://java.net/blogs/johnsmart http://www.wakaleo.com

https://java.net/blogs/johnsmart

http://www.wakaleo.com

@wakaleo#bddinactionuk

It’s testing, Jim, but not as we know it

John Ferguson Smart

Consultant Trainer Mentor Author Speaker Coder


Behaviour Driven Development



Using examples



Using examples a shared understanding




surface uncertainty




surface uncertainty software that matters



BDD



BDDCollaboration



BDD

Hunting out value

Collaboration



BDD

Hunting out value

Collaboration

Building the right software



BDD

Hunting out value Automated Acceptance Criteria

Collaboration




BDD


API and code design

Collaboration




BDD


API and code design

Collaboration

Building the software right




BDD


API and code design

Collaboration

Building the software right


Living Documentation


The business owner tells the business

analyst what he wants

12 The business

analyst writes a requirements

document

3 The developer translates the requirements into software

4 The tester translates the requirements

into test cases 5 The technical writer translates

the software into functional and technical

documentationA traditional development process

BDD in a nutshell


The business owner and the business

analyst have a conversation about

what he needs.

1

2

3

4 The tester uses these scenarios as the basis for

her tests

5

The automated tests provide feedback on progress and help

document the application

The business analyst, the developer and the tester elaborate the

requirements together.

The scenarios guide the developer and act as

automated tests

They define requirements as

structured, English-language format

"scenarios"

A BDD development process


The business owner and the business

analyst have a conversation about

what he needs.

1

2

3

4 The tester uses these scenarios as the basis for

her tests

5

The automated tests provide feedback on progress and help

document the application

The business analyst, the developer and the tester elaborate the

requirements together.

The scenarios guide the developer and act as

automated tests

They define requirements as

structured, English-language format

"scenarios"

A BDD development process

•Specifica8ons are elaborated collabora8vely •Specifica8ons use a common language •Executable specifica8ons provide fast feedback


Building software that matters

Building the thing right

Building the right thing

Wha

t

How

Mis

alig

ned

requ

irem

ents

Poor craftsmanship





Wha

t

How

Mis

alig

ned

requ

irem

ents

Poor craftsmanship

Solves the wrong problem well





Wha

t

How

Mis

alig

ned

requ

irem

ents

Poor craftsmanship


Solves the right problem poorly





Wha

t

How

Mis

alig

ned

requ

irem

ents

Poor craftsmanship

Buggy and useless







Wha

t

How

Mis

alig

ned

requ

irem

ents

Poor craftsmanship

Buggy and useless

Slow to change







Wha

t

How

Mis

alig

ned

requ

irem

ents

Poor craftsmanship

Buggy and useless

Hard to maintain

Slow to change







Wha

t

How

Mis

alig

ned

requ

irem

ents

Poor craftsmanship

Buggy and useless

Hard to maintain

Slow to change

Does what the business needs Reliable Easy to maintain



“Show me the money”



Business Goal

Business Goal

Business Goal

We start with a business goal



Business Goal

Business Goal

Business Goal

We start with a business goal

“Increase *cket sales by 5% over the next year by encouraging travelers to fly with Flying High

rather than with a rival company.”



Business Goal

Business Goal

Business Goal

What features will enable us to deliver this goal?

FeaturesFeaturesFeatures



Business Goal

Business Goal

Business Goal



Earn Frequent Flyer points from flights



Business Goal

Business Goal

Business Goal




Earn Frequent Flyer points from purchases



Business Goal

Business Goal

Business Goal




Earn Frequent Flyer points from purchases

View Frequent Flyer account balance online



Business Goal

Business Goal

Business Goal FeaturesFeaturesFeatures

We use conversa8ons around examples to build up our understanding of these features

FeaturesFeaturesExamples



Business Goal

Business Goal




“A new Frequent Flyer member starts off with Bronze status”



Business Goal

Business Goal





“If she earns 300 points, she becomes a Silver Frequent Flyer member”


Increase ticket sales revenue by 5%

Frequent Flyer members

Call centre staff

Buy more tickets

Encourage friends to join

Spend less time on phone sales

Purchase flights with redeemed miles

Purchase other goods with redeemed miles

Facebook and Twitter integration

Online sales

Why Who How What


Techniques like Impact Mapping can help us discuss what features are worth building


BDD - you don’t know what you don’t knowUnderstanding of what needs to be

delivered

Time



delivered

Time

Requirementsphase done

AnalysisPhase done



delivered

Time

Requirementsphase done

AnalysisPhase done

•Our ignorance decreases over 8me • It does not decrease at a linear rate • It does not always decrease in a predictable way


BDD - building a shared understanding



“Having the conversa/on is more important than

recording the conversa/on is more important than

automa/ng the conversa/on” -‐ Liz Keogh

Building a shared understanding

The essence of BDD



Story

bug reports

Working code boring

manual tes*ng

WASTEBA

Developer

TesterMany teams build features like this



A liKle collabora8on goes a long way

Story




StoryExamples




StoryExamplesAutomated acceptance criteria




Shared understanding





Working code and

Working Automated Acceptance Tests






Working code and

Working Automated Acceptance Tests

Exploratory tes*ng, usability tes*ng...




BDD - building a shared understandingBA and/or product owner

Tester Developer Automatable Acceptance Criteria



BDD - building a shared understandingBA and/or product owner

Tester Developer Automatable Acceptance Criteria


“The Three Amigos”



“The Three Amigos”


Discovering requirements through examples





“If I ask for the details about the flight FH-‐102, I should see that it is a Sydney to Hong Kong flight that leaves at 11:55pm ”





“If I ask for the details about the flight FH-‐102, I should see that it is a Sydney to Hong Kong flight that leaves at 11:55pm ”

•Explore requirements •Discover what we don’t know •Clarify ambigui8es • Iden8fy assump8ons and misunderstandings



We express the examples in a structured format using simple English phrases


Automated acceptance criteria

“It is fun to have fun But you have to know how”

*Dr Seuss, “The Cat in the Hat”

*


Automated acceptance criteria


Business Rules

Business Flow

Page/Component interac*ons

Page/Component/Service API

Write testing APIs, not test scripts


Work together!


Work together!

•Discuss tes8ng strategies in the “Three Amigos” sessions •Factor testability into the design •Developers and testers pair to implement the automated tests


Focus on business value


Living Documentation - completing the cycle



Illustrates delivered features



A star*ng point for manual tests






Progress repor*ng





Func*onal and technical documenta*on

Progress repor*ng



Living documenta8on gives an up-‐to-‐date overview of the project status



Test reports tell us…




How many tests passed




How many failed





How many failed


How many weren’t run




What tests exist for a given feature




What tests exist for a given feature

How stable the feature is




How a feature was tested




What a feature looks like


Living Documentation - DIY!


Living Documentation - DIY!

It’s the approach, not the tool



Test results do not tell us what was not tested



Feature Coverage tells us…




What do we plan to deliver?





What has been done?





What has been done? What is in progress






What hasn’t been started yet






What hasn’t been started yet

How many automated and manual tests were performed




What stories are defined for this

feature?





feature?

How many stories have automated acceptance criteria?





feature?

How many stories have automated acceptance criteria?

What acceptance criteria have been

automated?


BDD gotchas

12

3

4


BDD gotchas

12

3

4An8-‐paKern 1 The business analyst writes the scenarios and then gives them to the other team members.


BDD gotchas

12

3

4


BDD gotchas

12

3

4

An8-‐paKern 2 The tester writes the scenarios at the end to implement an automated test suite.


BDD gotchas

1

2

3

45


BDD gotchas

1

2

3

45

An8-‐paKern 3 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them aAerwards.


BDD gotchas

1

2

3

45


BDD gotchas

1

2

3

45

An8-‐paKern 4 The scenarios are too UI-‐centric or detail-‐focused, and neglect to express the core business value.


BDD benefits


BDD benefits

•Focus effort •Reduce waste and misaligned requirements


BDD benefits

Deliver more valuable soXware


BDD benefits

Make changes safely


BDD benefits

Faster and more reliable releases


BDD benefits

Reduced maintenance costs

@YourTwitterHandle#DVXFR14{session hashtag} @YourTwitterHandle#YourSessionHashtag

Q & A


Want to learn more?

http://thucydides.info/

http://thucydides.info/

its testing-jim-but-not-as-we-know-it-devoxx

Technology

wakaleo https

business analyst

software rightbuilding

requirements document3

technical writer

bddinactionukits testing

test cases

yoursessionhashtagits