Succeeding with

Specification by Example
Alistair McKinnell
@amckinnell
ICG
Intelligent Code
Generation
Specification by Example is a
collaborative method for specifying
requirements and tests
One Win
Three Failures
One Maybe
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.
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.
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
Development
Testing
Product
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
M A N N I N G
KAMIL NICIEJA
FOREWORD BY GOJKO ADŽIC´
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.
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.
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.
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
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
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
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
Requirements
FuturePast and current
User storiesExecutable
specifications
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
@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
The DeveloperTesting

Maturity Curve
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
Succeeding with Specification by Example

Succeeding with Specification by Example

  • 1.
    Succeeding with
 Specification byExample Alistair McKinnell @amckinnell
  • 2.
  • 4.
    Specification by Exampleis a collaborative method for specifying requirements and tests
  • 5.
  • 6.
    Unit testing Coding standards Continuousintegration 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® ProductSpecification 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 'doesnot 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.
  • 15.
    Development Testing Product Nulogy QCloud® Product Specification DocumentAbstract 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 NN I N G KAMIL NICIEJA FOREWORD BY GOJKO ADŽIC´
  • 17.
    Meet specification byexample 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 byexample 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 byexample 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 fromgoals 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 fromgoals 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 fromgoals Specifying collaboratively Specification by Example Illustrating requirements using examples Refining specifications Automating tests based on examples Validating frequently Living documentation
  • 23.
    13Meet specification byexample 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 UserstoriesExecutable specifications
  • 25.
    A user story… Anexecutable 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 theReview 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.
  • 28.
    Development Testing Product Nulogy QCloud® Product Specification DocumentAbstract 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