Upload
andrey-grave
View
296
Download
2
Embed Size (px)
DESCRIPTION
Intro to Specification By Example
Citation preview
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