Specification by example building the right thing
Intro to Specification By Example
Nov 29, 2014
Intro to Specification By Example
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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?
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 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.
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
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 Building wrong thing
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 Building wrong thing
Testing wrong thing
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 Building 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
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
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 understand spec
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
Loss of interest from business representatives
Hard to understand spec
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
Hard to understand spec
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
Q&A
Related Documents
