Imagine that you are responsible for guiding a software product during its next few releases... The developers on your team are diligently writing tests. You've never looked at the tests. The testers on your team can't seem to follow them. When customers audit your development process they ignore these tests even though your developers assure you the tests are easy to follow. You're working iteratively on the next release. You're making yourself available to the team. You're having great conversations. And yet, when features are delivered you realize the team misunderstood your perspective. Someone from support drops by with a question. No one on the team can remember exactly how that feature from the last release works. The document you created to guide development is out of date. Jira tickets lack detail. The developers start digging into the source code for answers. There has to be a better way. There is. It's called Specification by Example. Specification by Example is a collaborative software development apporach that facilitates collaboration by illustrating software requirements with concrete examples and automated acceptance tests. Alistair will show you how to succeed with Specification by Example by sharing his experiences from over ten years of implementing it with multiple teams.

1. Succeeding with
Specification by Example
Alistair McKinnell
@amckinnell

2. ICG
Intelligent Code
Generation

4. Specification by Example is a
collaborative method for specifying
requirements and tests

5. One Win
Three Failures
One Maybe

6. Unit testing
Coding standards
Continuous integration
Refactoring
Continuous deployment
Pair programming
Test-driven development (TDD)
Automated acceptance testing
Collective code ownership
Sustainable pace
Behavior-driven development (BDD)
Emergent design
75%
64%
54%
45%
37%
36%
35%
32%
31%
25%
17%
16%
*Respondents were able to make multiple selections.
Engineering Practices Employed
This year’s survey demonstrated an increased use of coding standards (64% compared to 56%
last year) and the use of continuous integration and refactoring were cited less as practices used.

12. Development
Testing
Product Nulogy QCloud®
Product Specification
Document Abstract
The following document is a functional product specification of Nulogy’s QCloud solution. This
document is intended to describe each module, structure and overall user environment, however is by
no means exhaustive of all functionality as product functionality enhancements are continuously
released every month.
Confidentiality Statement:
The information contained in this document is confidential and proprietary to Nulogy. This information
may not be used for any other purpose and may not be further distributed. Any recipient of this
document who is unwilling to agree to these restrictions should return the document to Nulogy without
reviewing the contents or making further distribution. Review of this document shall constitute
agreement to the restrictions stated above.

13. Development
Testing
Product it 'does not allow blank passwords' do
user = create_user(token: 'token')
encrypted_password_before = user.encrypted_password
put :update, params: { user: {
password: '',
password_confirmation: '',
reset_password_token: 'token'
} }
user.reload
expect(user.reset_password_token).to_not be_nil
expect(encrypted_password_before).to eq(user.encrypted_password)
end

14. Development
Testing
Product

15. Development
Testing
Product
Nulogy QCloud®
Product Specification
Document Abstract
The following document is a functional product specification of Nulogy’s QCloud solution. This
document is intended to describe each module, structure and overall user environment, however is by
no means exhaustive of all functionality as product functionality enhancements are continuously
released every month.
Confidentiality Statement:
The information contained in this document is confidential and proprietary to Nulogy. This information
may not be used for any other purpose and may not be further distributed. Any recipient of this
document who is unwilling to agree to these restrictions should return the document to Nulogy without
reviewing the contents or making further distribution. Review of this document shall constitute
agreement to the restrictions stated above.
it 'does not allow blank passwords' do
user = create_user(token: 'token')
encrypted_password_before = user.encrypted_password
put :update, params: { user: {
password: '',
password_confirmation: '',
reset_password_token: 'token'
} }
user.reload
expect(user.reset_password_token).to_not be_nil
expect(encrypted_password_before).to eq(user.encrypted_password)
end

16. M A N N I N G
KAMIL NICIEJA
FOREWORD BY GOJKO ADŽIC´

17. Meet specification by example and Gherkin
1. Plan
Software
development
life cycle
3. Launch
4. Feedback 2. Build
Specificati
Figure 1.2 SBE reimagines the software development process by prolonging
the specification process so that it takes place throughout the entire project.

18. Meet specification by example and Gherkin
1. Plan
Software
development
life cycle
3. Launch
4. Feedback 2. Build
Specificati
Figure 1.2 SBE reimagines the software development process by prolonging
the specification process so that it takes place throughout the entire project.

19. Meet specification by example and Gherkin
1. Plan
Software
development
life cycle
3. Launch
4. Feedback 2. Build
Specificati
Figure 1.2 SBE reimagines the software development process by prolonging
the specification process so that it takes place throughout the entire project.

20. Having conversations
Capturing
conversations
Automating
conversations
Deriving scope
from goals
Specifying
collaboratively
Specification by
Example
Illustrating
requirements
using examples
Refining
specifications
Automating tests
based on examples
Validating
frequently
Living
documentation

21. Having conversations
Capturing
conversations
Automating
conversations
Deriving scope
from goals
Specifying
collaboratively
Specification by
Example
Illustrating
requirements
using examples
Refining
specifications
Automating tests
based on examples
Validating
frequently
Living
documentation
Specification by Example is the art
of using examples in conversation
to illustrate behaviour

22. Having conversations
Capturing
conversations
Automating
conversations
Deriving scope
from goals
Specifying
collaboratively
Specification by
Example
Illustrating
requirements
using examples
Refining
specifications
Automating tests
based on examples
Validating
frequently
Living
documentation

23. 13Meet specification by example and Gherkin
If you’re curious about what a specification written in Gherkin looks like, look at this
example:
Feature: Setting starting points and destinations
Scenario: Starting point should be set to current location
Given a commuter that enabled location tracking
When the commuter wants to plan a journey
Then the starting point should be set to current location
1. Plan
Software
development
life cycle
3. Launch
4. Feedback 2. Build
Specification by example
Figure 1.2 SBE reimagines the software development process by prolonging
the specification process so that it takes place throughout the entire project.
Having conversations
Capturing
conversations
Automating
conversations
Deriving scope
from goals
Specifying
collaboratively
Specification by
Example
Illustrating
requirements
using examples
Refining
specifications
Automating tests
based on examples
Validating
frequently
Living
documentation

24. Requirements
FuturePast and current
User storiesExecutable
specifications

25. A user story…
An executable
specification…
Is discarded after implementation Is kept after implementation
Is a unit of change Is an effect of the change
Has acceptance criteria Is an acceptance test
Produces short-term results,
such as cards or tasks
Produces long-term
living documentation

26. @javascript
Feature: Configure the Review Sheets Operation
The Review Sheets operation will grant the user access to review sheets that has
been submitted by other users only if they also have the View Sheets operation.
Background:
* PackPlus is the example Company
* Polly Armstrong is a Policy Administrator
* Irene Hughes is a member of the Inspector User Group
* Polly Armstrong has enabled the View Sheets operation for an Inspector
* Polly Armstrong has enabled the Review Sheets operation for an Inspector
Scenario: the Review Sheets operation is enabled
Then Irene Hughes can review sheets
Scenario: the Review Sheets operation is disabled
When Polly Armstrong disables the Review Sheets operation for an Inspector
Then Irene Hughes cannot review sheets

27. The DeveloperTesting
Maturity Curve

28. Development
Testing
Product
Nulogy QCloud®
Product Specification
Document Abstract
The following document is a functional product specification of Nulogy’s QCloud solution. This
document is intended to describe each module, structure and overall user environment, however is by
no means exhaustive of all functionality as product functionality enhancements are continuously
released every month.
Confidentiality Statement:
The information contained in this document is confidential and proprietary to Nulogy. This information
may not be used for any other purpose and may not be further distributed. Any recipient of this
document who is unwilling to agree to these restrictions should return the document to Nulogy without
reviewing the contents or making further distribution. Review of this document shall constitute
agreement to the restrictions stated above.
it 'does not allow blank passwords' do
user = create_user(token: 'token')
encrypted_password_before = user.encrypted_password
put :update, params: { user: {
password: '',
password_confirmation: '',
reset_password_token: 'token'
} }
user.reload
expect(user.reset_password_token).to_not be_nil
expect(encrypted_password_before).to eq(user.encrypted_password)
end