Intro to Specification By Example

Specification by example

building the right thing

❖ software developer @BuyerDeck.com

❖ partner @craftsmans.lv

Who am I?

Andrey [email protected]

www.linkedin.com/in/andreygrave

❖ software developer @BuyerDeck.com

❖ partner @craftsmans.lv

Who am I?

Andrey [email protected]

www.linkedin.com/in/andreygrave

Jack-of-all-trades

Why I’m here?

I am fan of:❖ building valuable software❖ methods that help build valuable software❖ and particularly Specification by example

❖ What it is?❖ Why it is needed?❖ When to apply?❖ How to use?❖ Anti-patterns❖ Use cases❖ Q&A

Agenda

Terminology

Specification by example ATTD?Behaviour Driven Development

What it is?

Essentially, a light-weight specification of the system based on example behaviour.

#BDD in a tweet: Using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matter.

Dan North (@tastapod)

William Knight

What it is?“Specification by Example is a set of process patterns that facilitate change in software products to ensure that the right product is delivered efficiently.” Gojko Adzic

What challenges it tries to solve?

❖ knowing what to build❖ lack of shared understanding ❖ long feedback loops❖ multiple sources of truth

❖ to build the right thing❖ approach zero defects ❖ find bugs early❖ shared understanding❖ automated acceptance criteria❖ single source of truth

Why?

Why examples?

❖ easier to understand❖ harder to misinterpret❖ we already use them

Applicability

❖ Either complex business or complex organisation

❖ Doesn’t work well for purely technical problems❖ Doesn’t work well for UI focused software

products❖ Can be applied to legacy systems as well

“Specification By Example only works in the context of a working relationship where both

sides are collaborating and not fighting.” Martin Fowler

Usages

❖ investment banking❖ financial trading❖ insurance❖ airline ticket reservation❖ online gaming❖ micro-lending

How? Process patterns

❖ Collaborative specification❖ Illustrating specifications using examples❖ Refining the specification❖ Automating examples❖ Validating frequently❖ Living documentation

Specifying collaboratively

❖ Get together❖ Different perspectives❖ Collaboration patterns (specification workshop,

3 amigos)

Specification workshop

❖ Look for differences and conflicts❖ Seek for shared model using a ubiquitous

language❖ Don’t jump to implementation details at this

point

Example: HR vacations.

❖ Upon registering vacation for employee, vacation order need to be registered

❖ Vacation reserve report for employees show how many days left for given employee

Specification workshop result

Illustrating specifications using examples

❖ Given-When-Then scheme❖ Outputs first ❖ Inputs❖ Context❖ Why are these examples important?

Refining the specification

❖ Be precise ❖ Avoid “scripts” and “flows” ❖ Focus on business perspective❖ Avoid UI or technical details❖ Avoid covering every possible combination

Automating examples

The key point is that the automation layer needs to be kept very simple – just wiring of the

specification to the system under test (SUT).

Testing automation❖ Have a concise description❖ Have a clear model❖ Use business language❖ Show a clear connection between inputs and

outputs.❖ Specification, not script!❖ Easy to understand❖ Precise and testable

Tool overview

CONCORDION

Robot Framework

Tool overview

CEDAR

RoboSpock

Validating frequently

❖ Include example validation in Your development pipeline

❖ Execute them frequently❖ Examples can help track progress❖ Can show what got broken ❖ Consider an sprint “test pack”

Living documentation

❖ Keep specifications as simple and short as possible

❖ Organize specifications❖ Evolve specifications ❖ Make documentation accessible

Anti-patterns❖ No collaboration❖ Focusing on how not what❖ Too detailed or too UI centric examples❖ Underestimating effort required

No collaboration❖ Business analysts or developers writing

examples themselves.❖ Testers trying to handle all the acceptance

testing.❖ Business dictating tests.❖ Team members missing from spec workshops.




Many assumptions




Many assumptions Building wrong thing





Testing wrong thing





Testing wrong thing Unaware when code is finished

Solution: Collaborate❖ Business people, developers and testers give

input from their own perspectives.❖ Automated examples prove the team has built

the correct thing.❖ The collaboration process is more valuable than

the tests themselves.

Focusing on how, not what

❖ Duplication in tests❖ Very technical examples❖ Hard to understand examples❖ Slow tests❖ Large number of similar cases❖ Using examples as the ONLY tests



Hard to maintain

tests



Hard to maintain

tests

Hard to understand spec



Hard to maintain

tests

Loss of interest from business representatives


Solution: Focusing on what

❖ Don’t try to cover all possible cases ❖ Don’t forget to use different kind of tests❖ Keep examples as simple as possible❖ Examples should be easy understandable by

users of the system❖ Tools shouldn’t play an important part in

workshops

Scenarios are too UI or detail focused

❖ Scenarios contain JQuery selectors❖ Scenarios contain technical stuff (XML’s for

example)

Scenarios are too UI or detail focused

❖ Scenarios contain JQuery selectors❖ Scenarios contain technical stuff (XML’s for

example)Hard to maintain

tests

Loss of interest from business representatives


Solution: Focus on business

❖ Keep specification at business intent❖ Include business in creating and reviewing

specs❖ Hide all the details in the automation layer

Underestimating effort required

❖ Disillusionment and complaints❖ Blaming tools and process❖ Unnecessary stress❖ Resisting to change

Underestimating effort required

❖ Disillusionment and complaints❖ Blaming tools and process❖ Unnecessary stress❖ Resisting to change

Teams think they have

failed and get

disappointed early.

Solution: Be prepared

❖ Benefits are not immediately apparent, even while team practices are being (dramatically) changed

❖ Introducing SbE is challenging❖ Requires time and investments ❖ Automated testing doesn’t come for free

Use case #1. Payment charging.❖ Integration with bank through files❖ Payments can be canceled within 5 business

days❖ Applied write & review❖ Struggling with tools (where to put

specifications Wiki, or right as cucumber features)

❖ testing through UI

Use case #1. Lessons learned.

❖ SpE is not easy as it seemed❖ Learn tooling❖ It’s hard to write specs on existing system

Use case #2. Loan application handler

❖ new project❖ co-located team❖ freedom❖ real specification workshop❖ automated tests worked quite well

Use case #2. Lessons learned.

❖ Collaboration workshop is awesome!❖ It’s a lot easier to work when You have

acceptance tests in front of You❖ SpE works even without Cucumber

Recap

❖ get together❖ specify using examples❖ clean up and improve examples❖ automate examples❖ write code which satisfies examples❖ deploy❖ live happily ever after

Recap

❖ get together❖ specify using examples❖ clean up and improve examples❖ automate examples❖ write code which satisfies examples❖ deploy❖ live happily ever after

Repeat for next user story

Know the benefits

❖ increased quality❖ reduced waste❖ reduced risk of production defects❖ focused effort❖ changes can be made more safely❖ improved business involvement

Know the benefits

❖ increased quality❖ reduced waste❖ reduced risk of production defects❖ focused effort❖ changes can be made more safely❖ improved business involvement

But remember that it will not be easy.

“Having a conversation is more important than

recording the conversationis more important than

automating the conversation”

Liz Keogh

Thank You!MAKE IMPACT NOT SOFTWARE

Intro to Specification By Example

Technology

Transcript of Intro to Specification By Example