How to Deliver the Right

SoftwareAsier Barrenetxea

What is the single greatest cause of software failure?

Requirements!

Requirements

are wrong.

are badly written.

are incomplete.

The programmers and the specifiers understand the requirements differently.

Classical approach:testing at the end

Requirements

Development Testing

Hand over of requirements

Each source telling a different story

Tests ≃ Requirements

How system really works ≃ Requirements

Documentation get stale

Late feedback

Business misunderstands get arisen late on the process

When developer implementing requirements.

When qa testing it.

When software gets into production.

Big WASTE

Spec by example to the

rescue

Bring testing to the front

Requirements +

Testing

Development

Verification(automated)

Use examples

Easy to understand

Plain English

Unambiguous

Write examples collaboratively

Business people, developers and testers in the same room.

Transfer the knowledge.

Learn about the domain.

Ubiquitous language.

Early feedback of misunderstandings.

In 30 min meeting can find out things that it would take a whole iteration or even more.

everybody understands the same thing.

Write examples collaboratively

Inconsistencies and gaps are easy to spot when you write down the rules.

Find out incorrect assumptions.

Find out real business value.

Everybody gets this feeling of ownership.

Different approaches:

Three amigos

One developer with a stakeholder/domain expert

Whole team with stakeholders

Specification workshop

Specification workshop

For harder to specificy stories.

Meeting with 10+ people. POs, BAs, devs, QAs..

Bring people from other teams if necessary.

Create 3 teams and write examples in one board each.

Compare. Look for inconsistencies. Why do we have them?

Automate examples

Map examples to executable tests.

Use tools as Specflow, Cucumber, Fitness..

Do not modify examples when automating.

Automate examles

Brittle UI tests?

Do not couple your examples to the UI.

Page Objects https://code.google.com/p/selenium/wiki/PageObjects

Tests don’t have to go always through the UI!

Test pyramid. http://martinfowler.com/bliki/TestPyramid.html

Implement examples

Developers will have to code just what was specified.

Make the tests green -> Done.

Single source of truth

Examples = Requirements.

Examples = Automated tests.

Examples = What the system does.

Living documentation

Run examples with every change to the system.

Documentation never gets out-dated.

All tests green -> system is doing what examples say.

User stories

Relate examples with user story.

Gives context.

Focus on business goal.

As a <role>

I want <software feature>

In order to  <goal/desire> 

I order to <goal/desire> 

as a <role>

so that <software feature>

Gherkin syntax

Given -> arrange

When -> action

Then -> assert

What makes a good example

Focused on a single thing.

Self explanatory.

Uses the domain language.

SMART

Specific

Measurable

Achievable

Relevant

Time-bound.

Do not automate EVERYTHING

There would always be some manual testing.

Usability testing.

Exploratory testing.

Be aware.

Examples of examples

Conversation brings new scenarios to the table

Communication > Automation

The important thing is to communicate

Automation and tools are nice, but don’t get your main focus on them

“Individuals and interactions over processes and tools”

- Agile Manifesto

“I want to bridge the gap between business people and technical people”

- Kent Beck about XP

More Info + resources

Book. Specification by Example: How Successful Teams Deliver the Right Software , Gojko Adzichttp://www.amazon.co.uk/Specification-Example-Successful-Deliver-Software/dp/1617290084

Blog post. A.T. FAIL!, Robert C. Martinhttp://blog.8thlight.com/uncle-bob/2013/09/26/AT-FAIL.html

Specification by Example and Agile Acceptance Testing, Gojko Adzichttp://www.slideshare.net/gojkoadzic/specification-by-example-and-agile-acceptance-testing

My blog post.http://asierba.net/2014/04/03/spec-by-example/

Questions?