Behaviour-Driven Development
is not about Testing
Dan North
@tastapod
Slide 2
Slide 2 text
Motivation
Slide 3
Slide 3 text
Motivation
Testers feeling “left behind” by Agile
Slide 4
Slide 4 text
Motivation
Testers feeling “left behind” by Agile
Testers writing hundreds of “BDDs”
Slide 5
Slide 5 text
Motivation
Testers feeling “left behind” by Agile
Testers writing hundreds of “BDDs”
Hiring for “automation testers”
Slide 6
Slide 6 text
Motivation
Testers feeling “left behind” by Agile
Testers writing hundreds of “BDDs”
Hiring for “automation testers”
Generally poor training around “agile testing”
Slide 7
Slide 7 text
Motivation
Testers feeling “left behind” by Agile
Testers writing hundreds of “BDDs”
Hiring for “automation testers”
Generally poor training around “agile testing”
Testers unsettled about the role of SET/SDET
tl;dr
1. Programmers don’t understand testing
2. Agile doesn’t understand testing
3. BDD is appealing to testers
Slide 12
Slide 12 text
tl;dr
1. Programmers don’t understand testing
2. Agile doesn’t understand testing
3. BDD is appealing to testers
4. BDD is not about testing
Slide 13
Slide 13 text
We need to talk about testing…
Slide 14
Slide 14 text
Why do we have testing?
Slide 15
Slide 15 text
Why do we have testing?
Mandated by the SDLC
Slide 16
Slide 16 text
Why do we have testing?
Mandated by the SDLC
Programmers see testing as an irritation
Slide 17
Slide 17 text
Why do we have testing?
Mandated by the SDLC
Programmers see testing as an irritation
Project managers see testing as a source of risk
Slide 18
Slide 18 text
Why do we have testing?
Mandated by the SDLC
Programmers see testing as an irritation
Project managers see testing as a source of risk
Testing is always the thing that gets squeezed
Slide 19
Slide 19 text
Why do we have testing?
Mandated by the SDLC
Programmers see testing as an irritation
Project managers see testing as a source of risk
Testing is always the thing that gets squeezed
Non-differentiating, non-critical
Slide 20
Slide 20 text
Purpose Alignment model
Business Critical
Differentiating
Slide 21
Slide 21 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Slide 22
Slide 22 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?” Parity
Slide 23
Slide 23 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Partner
Parity
Slide 24
Slide 24 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Partner “Invest and Excel”
Parity
Slide 25
Slide 25 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Partner “Invest and Excel”
Parity
Testing!
Slide 26
Slide 26 text
The goal of testing…
Slide 27
Slide 27 text
The goal of testing…
“to find information”?
Slide 28
Slide 28 text
The goal of testing…
“to find information”?
“to communicate”?
Slide 29
Slide 29 text
The goal of testing…
“to find information”?
“to communicate”?
to enable us to “reasonably believe that the probability is low that
the product still has important undiscovered problems”?
Slide 30
Slide 30 text
–Kent Beck
"I get paid for code that works, not for tests, so
my philosophy is to test as little as possible to
reach a given level of confidence."
http://stackoverflow.com/a/153565/632259
Slide 31
Slide 31 text
The goal of testing…
Slide 32
Slide 32 text
The goal of testing…
to increase confidence for stakeholders through evidence
Slide 33
Slide 33 text
The goal of testing…
to increase confidence for stakeholders through evidence
Slide 34
Slide 34 text
The goal of testing…
to increase confidence for stakeholders through evidence
Slide 35
Slide 35 text
The goal of testing…
to increase confidence for stakeholders through evidence
Slide 36
Slide 36 text
A good tester has 3 superpowers…
to increase confidence for stakeholders through evidence
Slide 37
Slide 37 text
A good tester has 3 superpowers…
to increase confidence for stakeholders through evidence
Empathy
Slide 38
Slide 38 text
A good tester has 3 superpowers…
to increase confidence for stakeholders through evidence
Empathy
Ingenuity
Slide 39
Slide 39 text
A good tester has 3 superpowers…
to increase confidence for stakeholders through evidence
Empathy
Balance
Ingenuity
Slide 40
Slide 40 text
1. Programmers don’t understand testing
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
No content
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Partner
Testing!
“Invest and Excel”
Parity
Slide 48
Slide 48 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Partner
Testing!
“Invest and Excel”
Parity
Slide 49
Slide 49 text
2. Agile doesn’t understand testing
Slide 50
Slide 50 text
Agile doesn’t understand testing
Slide 51
Slide 51 text
Agile doesn’t understand testing
Agile methods were invented by programmers
Slide 52
Slide 52 text
Agile doesn’t understand testing
Agile methods were invented by programmers
Testing is implied but never explicit
Slide 53
Slide 53 text
Agile doesn’t understand testing
Agile methods were invented by programmers
Testing is implied but never explicit
The tester role is missing or poorly defined
BDD is appealing to testers…
We acknowledge multiple stakeholders
Slide 74
Slide 74 text
BDD is appealing to testers…
We acknowledge multiple stakeholders
We discuss acceptance criteria from the outset
Slide 75
Slide 75 text
BDD is appealing to testers…
We acknowledge multiple stakeholders
We discuss acceptance criteria from the outset
Everything happens from the perspective of the stakeholders!
Slide 76
Slide 76 text
BDD is appealing to testers…
We acknowledge multiple stakeholders
We discuss acceptance criteria from the outset
Everything happens from the perspective of the stakeholders!
We increase confidence for stakeholders through evidence
Slide 77
Slide 77 text
BDD is appealing to testers…
We acknowledge multiple stakeholders
We discuss acceptance criteria from the outset
Everything happens from the perspective of the stakeholders!
We increase confidence for stakeholders through evidence
It’s not surprising BDD often starts with testers
Slide 78
Slide 78 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Partner
Testing!
“Invest and Excel”
Parity
Slide 79
Slide 79 text
Purpose Alignment model
Business Critical
Differentiating
“Who cares?”
Partner
Testing!
“Invest and Excel”
Parity
Slide 80
Slide 80 text
4. BDD is not about testing!
Slide 81
Slide 81 text
The lifecycle of a scenario
Slide 82
Slide 82 text
The lifecycle of a scenario
Starts as enabling constraint to guide the design
Slide 83
Slide 83 text
The lifecycle of a scenario
Starts as enabling constraint to guide the design
Then: checks* the solution
Slide 84
Slide 84 text
The lifecycle of a scenario
Starts as enabling constraint to guide the design
Then: checks* the solution
May be useful as documentation
Slide 85
Slide 85 text
The lifecycle of a scenario
Starts as enabling constraint to guide the design
Then: checks* the solution
May be useful as documentation
May form the basis of automated tests
Slide 86
Slide 86 text
The lifecycle of a scenario
Starts as enabling constraint to guide the design
Then: checks* the solution
May be useful as documentation
May form the basis of automated tests
*check: (vt) inspect, investigate, examine, verify
Slide 87
Slide 87 text
Scenario as the basis of tests
Slide 88
Slide 88 text
Scenario as the basis of tests
What general case is this an example of?
Slide 89
Slide 89 text
Scenario as the basis of tests
What general case is this an example of?
How could I gain confidence in the general case?
Slide 90
Slide 90 text
Scenario as the basis of tests
What general case is this an example of?
How could I gain confidence in the general case?
Which stakeholder does this serve? What else do they need?
Slide 91
Slide 91 text
Scenario as the basis of tests
What general case is this an example of?
How could I gain confidence in the general case?
Which stakeholder does this serve? What else do they need?
Which stakeholders have we not yet served?
Slide 92
Slide 92 text
Scenario as the basis of tests
What general case is this an example of?
How could I gain confidence in the general case?
Which stakeholder does this serve? What else do they need?
Which stakeholders have we not yet served?
Scenarios are necessary but not sufficient for testing
Slide 93
Slide 93 text
What does a good automated test look like?
Slide 94
Slide 94 text
What does a good automated test look like?
Intention-revealing name
Slide 95
Slide 95 text
What does a good automated test look like?
Intention-revealing name
Intention-revealing errors
Slide 96
Slide 96 text
What does a good automated test look like?
Intention-revealing name
Intention-revealing errors
Consistent language
Slide 97
Slide 97 text
What does a good automated test look like?
Intention-revealing name
Intention-revealing errors
Consistent language
The intent, the whole intent and nothing but the intent
Slide 98
Slide 98 text
What does a good automated test look like?
Intention-revealing name
Intention-revealing errors
Consistent language
The intent, the whole intent and nothing but the intent
Fast! “Close to the action”
Slide 99
Slide 99 text
What does a typical gherkin scenario look like?
Intention-revealing name
Intention-revealing errors
Consistent language
The intent, the whole intent and nothing but the intent
Fast! “Close to the action”
Slide 100
Slide 100 text
What does a typical gherkin scenario look like?
Intention-revealing name
Intention-revealing errors
Consistent language
The intent, the whole intent and nothing but the intent
Fast! “Close to the action”
Slide 101
Slide 101 text
What does a typical gherkin scenario look like?
Intention-revealing name
Intention-revealing errors
Consistent language
The intent, the whole intent and nothing but the intent
Fast! “Close to the action”
Slide 102
Slide 102 text
What does a typical gherkin scenario look like?
Intention-revealing name
Intention-revealing errors
Consistent language
The intent, the whole intent and nothing but the intent
Fast! “Close to the action”
??
Slide 103
Slide 103 text
What does a typical gherkin scenario look like?
Intention-revealing name
Intention-revealing errors
Consistent language
The intent, the whole intent and nothing but the intent
Fast! “Close to the action”
??
??
Slide 104
Slide 104 text
Good scenarios != Good tests
Slide 105
Slide 105 text
BDD is not about testing, however…
Slide 106
Slide 106 text
BDD is not about testing, however…
Testing is complementary to BDD
Slide 107
Slide 107 text
BDD is not about testing, however…
Testing is complementary to BDD
Testing is the sufficient to BDD’s necessary
Slide 108
Slide 108 text
BDD is not about testing, however…
Testing is complementary to BDD
Testing is the sufficient to BDD’s necessary
Test thinking is critical to successful delivery
Slide 109
Slide 109 text
BDD is not about testing, however…
Testing is complementary to BDD
Testing is the sufficient to BDD’s necessary
Test thinking is critical to successful delivery
Testability starts with design
Slide 110
Slide 110 text
BDD is not about testing, however…
Testing is complementary to BDD
Testing is the sufficient to BDD’s necessary
Test thinking is critical to successful delivery
Testability starts with design
software that matters, for “people whose lives you touch”