Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Specification By Example - ANZTB

No description

Nigel Charman

on 29 March 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Specification By Example - ANZTB

In the real
World Introduction Quick example Thank you! Goals Approach Zero Defects
Find bugs early to:
reduce costs,
improve speed-to-market,
maintain reputation
Bridge the Communication Gap
Build the right thing Just What is it Specification by Example, also known
A collaborative approach to elucidate and prove requirements using examples. Lolly Calculator Many hurdles (practice pitfalls)
Might not make you any faster
(but will reduce rework due to bugs)
Will blur roles within teams Benefits come
from the process 1. Break work into functional blocks
2. Define acceptance criteria
3. Team collaborates on developing examples
4. Individual creates specification with examples
5. Developer automates examples as tests
6. Developer implements application code
7. Test results are embedded in specification Teams will change The key is collaboration Focus on business intentions Without Collaboration The cross-team collaboration is more valuable than the tests themselves. Many assumptions
Build wrong thing
Test wrong things
Dead end development
Unaware when code is finished. Business specifications and examples should be perfectly understandable by users of the system.

Specifications define WHAT a feature does, and NOT HOW it does it.

Focussing on HOW may result in not meeting the business intent

Release your teams to implement the best solution they can devise. Management buy-in is essential
Team is responsible for quality
Focus on testing early
Devs are testers too (and testers are devs)
Team commits to collaboration
Encourage communication across disciplines
Learn new process and tools
Smaller iterations (ideally agile)
Independent, testable user-focused stories
Minimum Viable Product
Hire a coach What can you achieve? In our Experience:
Approach Zero defects
Increased collaboration
Greater business involvement
Finding critical defects before production
Increased confidence Cost development time production inception point at which you
find the bug Business technology Spec by example As a forgetful sweet shop owner I want to calculate basic sums so that I am not fleeced by small children.

Acceptance Criteria

I can quickly calculate the cost of my lolly bags.
I can calculate the change to give the customer.
I can split the bill among a group of children. Questions ? Examples are easy to understand
Hairdressing... I can specify in minute technical detail how I want my bonce to look.

Or... I can give them a suitable example I want to look like this... As a forgetful sweetshop owner, this is what I notice:
It's not testing clicks and fields, it is testing my business intentions.
The examples are written in my language
I have confidence the team is building the right thing, and we all see the results.
The spec translates between me and the development team. Testers still do exploratory, look and feel, performance, security, load etc

(Reduced need for repeated manual test scripts) Test examples automatically run on every code change How it works
as part of a testing strategy Why examples? Prove to stakeholders we built what we said we would build. In the stakeholders language. What people said.. “Previously we’d have gone into production with forty or fifty known defects ranging in severity, this time we’ve gone in with no known-defects, which is just unheard of.” “Before, there were no projects going live without defects. There would be a huge list of priority three or priority four defects and the BA would sit down with the business to decide what was fixed. Many were never fixed. There was generally a big chunk that they didn’t want to delay implementation for.”

“This has changed. No known-defects have gone into production.” “I attended a project review recently, and the business was blown away by the quality. Usually you get niggles when you go into production, but they could not have been happier.” Building Quality In Building the right thing - Specification by Example
Building the thing right - Unit Test Testing Nigel Charman
William Knight Specification
By Example Software Developer for over 20 years
Technical Practices Consultant at Assurity since '06
Using Specification by Example for 4 years
Committer to Concordion core project Software Developer for over 20 years
Technical Practices Consultant at Assurity Assurity Consulting Limited Results “Time and time again, when we changed something, the automation fails and sure as little green apples it’s a bug that we’d never have found without the automation. It’s worth its weight in gold.” Specification by Example targets
acceptance testing and fosters
collaboration 3.4) The product shall have a gasoline-powered engine.

3.5) The product shall have four wheels.

3.5.1) The product shall have a rubber tire mounted to each wheel.

3.6) The product shall have a steering wheel.

3.7) The product shall have a steel body. How The product makes it easy and fast for me to mow my lawn.
I am comfortable while using the product. What Deployment Pipeline nigel.charman@assurity.co.nz
Full transcript