Tài liệu Specification by Example: How Successful Teams Deliver the Right Software doc

LINK DOWNLOAD MIỄN PHÍ TÀI LIỆU "Tài liệu Specification by Example: How Successful Teams Deliver the Right Software doc": http://123doc.vn/document/1045892-tai-lieu-specification-by-example-how-successful-teams-deliver-the-right-software-doc.htm

Contents
Contents v

Preface xiii

Acknowledgments xxii

About the author xxiii

About the cover illustration xxiv

PART 1 Getting Started
1
Key benefits 3 
Implementing changes more efficiently 6

Higher product quality 8

Less rework 12

Better work alignment 14

Remember 16

2
Key process patterns 17 
Deriving scope from goals 19

Specifying collaboratively 19

Illustrating using examples 20

Refining the specification 20

Automating validation without changing specifications 21

Validating frequently 23

Evolving a documentation system 24

A practical example 24

Business goal 24

An example of a good business goal 24
Scope 25
User stories for a basic loyalty system 25

Key examples 25
Key Examples: Free deliv
ery
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Specification with examples 26
Free delivery 26

Examples 26
Executable specification 27
Living documentation 27
Remember 28
3
Living documentation 29 
Why we need authoritative documentation 30
Tests can be good documentation 31
Creating documentation from executable specifications 32
Benefits of the documentation-centric model 34
Remember 35
www.it-ebooks.info









4
Initiating the changes 36

How to begin changing the process
37

Implement Specification by Example as part of a wider process change

Start with functional test automation

Introduce a tool for executable specifications

Use test-driven development as a stepping stone
Avoid “agile” terminology
Keep one person on legacy scripts during migration
Track who is running—and not running—automated checks
Get sign-off on exported living documentation
Get sign-off on scope, not specifications
Get sign-off on “slimmed down use cases”
Introduce use case realizations
When: On greenfield projects 38

Focus on improving quality
38

When: Appying to an existing project 39

When: Testers own test automation 41

When: Developers have a good understanding of TDD 42
How to begin changing the team culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

When: Working in an environment that’s resistant to change 43
Ensure you have management support
44

Sell Specification by Example as a better way to do acceptance testing
45

Don’t make test automation the end goal
46

Don’t focus on a tool
47

When: Introducing functional automation to legacy systems 48
When: Developers are reluctant to participate 49

How teams integrated collaboration into flows and iterations 49

Global talent management team at ultimate software . . . . . . . . . . . . . . . . . . . . . . . . . 51

Sierra team at BNP paribas 52

Sky Network services 53

Dealing with sign-off and traceability 55

Keep executable specifications in a version control system
56

When: Signing off iteration by iteration 56
When: Signing off longer milestones 57
When: Regulatory sign-off requires details 57
When: All details are required for sign-off 59
Warning signs 59
Watch out for tests that change frequently 60
Watch out for boomerangs 60
Watch out for organizational misalignment 61
Watch out for just-in-case code 61
Watch out for shotgun surgery 62
Remember 62
www.it-ebooks.info




PART 2
Key process patterns
5
Deriving scope from goals 65

Building the right scope
67

Have developers provide the “I want” part of user stories
Make sure teams deliver complete features
Understand the “why” and “who”
68

Understand where the value is coming from
69

Understand what outputs the business users expect
70

When: Business users trust the development team 71
Collaborating on scope without high-level control 72

Ask how something would be useful
73

Ask for an alternative solution
73

Don’t look only at the lowest level
74

When: Large multisite projects 75
Further information 75

Remember 76

6
Specifying collaboratively 77 
Why do we need to collaborate on specifications? 77

Try big, all-team workshops
Try smaller workshops (“Three Amigos”)
Pair-writing
Have developers frequently review tests before an iteration
Try informal conversations
Hold introductory meetings
Undertake detailed preparation and review up front
Have team members review stories early
Prepare only initial examples

The most popular collaborative models 79

When: Starting out with specification by example 79
When: Domain requires frequent clarification 81

When: Mature products 83
When: Analysts writing tests 84

When: Business stakeholders are readily available 85
Preparing for collaboration 86
When: Project has many stakeholders 87
Involve stakeholders
87
When: Remote Stakeholders 89
When: Analysts/domain experts are a bottleneck 90
When: Stakeholders are readily available 91
Don’t hinder discussion by overpreparing
92
Choosing a collaboration model 93
Remember 94
vii
www.it-ebooks.info








7
Illustrating using examples 95

Illustrating using examples: an example
97

Don’t have yes/no answers in your examples

Avoid using abstract classes of equivalence

Ask for an alternative way to check the functionality
Avoid making up your own data
Get basic examples directly from customers
Get precise performance requirements
Try the QUPER model
Use a checklist for discussions

Build a reference example
Examples should be precise
99

When: The underlying concept isn’t separately defined 99

When: You can specify a concrete example 100

Examples should be complete 100

Experiment with data
101

When: Complex/legacy infrastructures 101
Examples should be realistic 102

When: Data-driven projects 102
When: Working with enterprise customers 103

Examples should be easy to understand 105

Avoid the temptation to explore every combinatorial possibility
105

Look for implied concepts
106

Illustrating nonfunctional requirements 107

When: Performance is a key feature 108
Use low-fi prototypes for UI
109

When: Sliding scale requirements 110
When: Cross-cutting concerns 111

When: Requirements are impossible to quantify 112
Remember 113

8
Refining the specification 114 
An example of a good specification 116
Resist the temptation to work around technical difficulties in specifications
Don’t get trapped in user interface details
Free delivery 116
Examples 116
An example of a bad specification 117
What to focus on when refining specifications 119
Examples should be precise and testable 119
Scripts are not specifications 119
Don’t create flow-like descriptions
120
Specifications should be about business functionality, not software design 121
Avoid writing specifications that are tightly coupled with code
121
When: Working on a legacy system 122
When: Web projects 124
viii
www.it-ebooks.info




9
Specifications should be self-explanatory
124

Show and keep quiet

When: Someone is working on specifications alone

Start with basic examples; then expand through exploring

Use “Given-When-Then” language in specifications

Don’t explicitly set up all the dependencies in the specification
Don’t always rely on defaults
Use a descriptive title and explain the goal using a short paragraph
125

In order to: Check whether a specification is self-explanatory 125

Don’t overspecify examples
126

When: Describing rules with many parameter combinations 128

In order to: Make the test easier to understand 128
When: Dealing with complex dependencies/referential integrity 130
Apply defaults in the automation layer
131

When: Working with objects with many attributes 131

Specifications should be in domain language 132

Refining in practice 132

Remember 135

Automating validation without changing specifications 136 
Is automation required at all? 137

To learn about tools, try a simple project first
Gain trust with user interface tests
Automate along system boundaries
Automate below the skin of the application

Check only UI functionality with UI specifications
Avoid using prepopulated data
Starting with automation 139

When: Working on a legacy system 139

Plan for automation upfront
140

Don’t postpone or delegate automation
141

Avoid automating existing manual test scripts
142

When: Team members are skeptical about executable specifications 143

Managing the automation layer 144

Don’t treat automation code as second-grade code
145
Describe validation processes in the automation layer
146
Don’t replicate business logic in the test automation layer
147
When: Complex integrations 148
Don’t check business logic through the user interface
149
When: Checking session and workflow constraints 150
Automating user interfaces 152
Specify user interface functionality at a higher level of abstraction
153
When: User interface contains complex logic 154
Avoid recorded UI tests
155
Set up context in a database
157
Test data management 157
When: Specifying logic that’s not data driven 158
ix
www.it-ebooks.info

Try using prepopulated reference data

When: Data-driven systems 158

Pull prototypes from the database

When: Legacy data-driven systems 160

Remember
161

10
Validating frequently 162

Reducing unreliability
164

Find the most annoying thing, fix it, and repeat
Identify unstable tests using CI test history
Create simpler test doubles for external systems
Selectively isolate external systems

Try multistage validation
Execute tests in transactions
Run quick checks for reference data
Make asynchronous processing optional
Don’t use executable specifications as end-to-end validations
When: Working on a system with bad automated test support 164
When: Retrofitting automated testing into a legacy system 165

Set up a dedicated continuous validation environment
166

Employ fully automated deployment
166

When: Working with external reference data sources 167
When: External systems participate in work 168
When: Large/multisite groups 168
When: Executable specifications modify reference data 169
When: Data-driven systems 170
Wait for events, not for elapsed time
170

When: Greenfield projects 171
When: Brownfield projects 172
Getting feedback faster 173

Introduce business time
Avoid using in-memory databases for testing
Separate quick and slow tests

Keep overnight packs stable

Parallelize test runs
Try disabling less risky tests
When: Working with temporal constraints 173
Break long test packs into smaller modules
174
When: Data-driven systems 174
When: A small number of tests take most of the time to execute 175

When: Slow tests run only overnight 176

Create a current iteration pack
177
When: You can get more than one test environment 177
When: Test feedback is very slow 178
Managing failing tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Create a known regression failures pack
180
Automatically check which tests are turned off
When: Failing tests are disabled, not moved to a separate pack 181
Remember 182
x
www.it-ebooks.info







Evolving a documentation system 183

11
Living documentation should be easy to understand
183

Avoid using technical automation concepts in tests

Base the specification language on personas
Collaborate on defining the language
Organize along UI navigation routes
Organize along business processes
Use tags instead of URLs when referring to executable specifications
Don’t create long specifications
184

Don’t use many small specifications to describe a single feature
184

Look for higher-level concepts
185

When: Stakeholders aren’t technical 185

Living documentation should be consistent 186

Evolve a language
187

When: Web projects 188
When: Choosing not to run specification workshops 189

Document your building blocks
190

Living documentation should be organized for easy access 191

Organize current work by stories
191

Reorganize stories by functional areas
192

When: Documenting user interfaces 193
When: End-to-end use case traceability required 194

When: You need traceability of specifications 195
Listen to your living documentation 196

Remember 197

PART 3 Case studies
12
uSwitch 201 
Starting to change the process 202
Optimizing the process 204
The current process 207
The result 208
Key lessons 209
13
RainStor 211 
Changing the process 211
The current process 213
Key lessons 215
14
Iowa Student Loan 217 
Changing the process 217
Optimizing the process 218
Living documentation as competitive advantage 222
Key lessons 223
xi
www.it-ebooks.info









15
Sabre Airline Solutions 224

Changing the process
224

Improving collaboration
226

The result
228

Key lessons
229

16
ePlan Services 230

Changing the process 230

Living documentation 233

Current process 234

Key lessons 236

17
Songkick 237 
Changing the process 238

Current process 241

Key lessons 242

18
Concluding thoughts 245 
Collaboration on requirements builds trust between stakeholders

and delivery team members 245

Collaboration requires preparation 246

There are many different ways to collaborate 247

Looking at the end goal as business process documentation is a useful model 247

Long-term value comes from living documentation 248

Appendix A Resources 250 
Index 255

xii
www.it-ebooks.info








Preface
T
he book you hold in your hands, or see on your screen, is the result of a series
of studies of how teams all over the world specify, develop, and deliver the
right software, without defects, in very short cycles. It presents the collective
knowledge of about 50 projects, ranging from public websites to internal back-office
systems. These projects involved diverse teams, from small ones working in the same of-
fice to groups spread across different continents, working in a range of processes includ-
ing Extreme Programming (XP), Scrum, Kanban, and similar methods (often bundled
together under the names
agile
and
lean
). They have one thing in common—they all got
the practices of collaborating on specifications and tests right, and they got big benefits
out of that.
Specification by Example
Different teams use different names for their ways of dealing with specifications and
tests, yet they all share a common set of core principles and ideas, which I hold to be
essentially the same thing. Some of the names that the teams used for these practices are
•
Agile acceptance testing
•
Acceptance Test-Driven Development
•
Example-Driven Development
•
Story testing
•
Behavior-Driven Development
•
Specification by Example
The fact that the same practices have so many names reflects the huge amount of inno-
vation in this field at the moment. It also reflects the fact that the practices described in
this book impact the ways teams approach specifications, development, and testing. To
be consistent, I had to choose one name. I settled on
Specification by Example
, and I’ll
use that in the rest of the book. I explain this choice in detail in the “A few words on the
terminology” section later in this introduction.
In the real world
I present this topic through case studies and interviews. I chose this approach so that you
can see that there are real teams out there right now doing this and reaping big benefits.
Specification by Example is not a dark art although some popular media might make
you think that.
xiii
www.it-ebooks.info






Almost everything in this book is from the real world, real teams, and real experi-
ences. A small number of practices are presented as suggestions without being backed
by a case study. These are ideas that I think will be important for the future, and they’re
clearly introduced as such.
I’m certain that the studies I conducted leading to this book and my conclusions
will be dismissed for not being a serious scientific research by those skeptics who claim
that agile development doesn’t work and that the industry should go back to “real soft-
ware engineering.”
1
That’s fine. The resources available to me for this book project are
minute compared to what would be required for a serious scientific research. Even with
those resources, I’m not a scientist, nor do I intend to present myself as such. I’m a
practitioner.
Who should read this book?
If you’re a practitioner, like me, and your bread and butter come from making or helping
software go live, this book has a lot to offer. I primarily wrote this book for teams who
have tried to implement an agile process and ran into problems that manifest themselves
as poor quality, rework, and missed customer expectations. (Yes, these are problems, and
plainly iterating is a workaround and not a solution.) Specification by Example, agile
acceptance testing, Behavior-Driven Development, and all the alternative names for the
same thing solve these problems. This book will help you get started with those prac-
tices and learn how to contribute better to your team, regardless of whether you qualify
yourself as a tester, developer, analyst, or product owner.
A few years ago, most people I met at conferences hadn’t heard of these ideas. Most
people I meet now are somewhat aware of these practices, but many failed to implement
them properly. There’s very little literature on problems that teams face while imple-
menting agile development in general, so every discouraged team thinks that they’re
unique and that somehow the ideas don’t work in their “real world.” They seem sur-
prised how I can guess three or four of their biggest problems after just five minutes of
listening to them. They are often completely astonished that many other teams have the
same issues.
If you work in such a team, the first thing that this book will do for you is show
you that you’re not alone. The teams I interviewed for this book aren’t perfect—they
had tons of issues as well. Instead of quitting after they hit a brick wall, they decided to
drive around it or tear it down. Knowing this is often encouraging enough for people to
1
For more on the delusion that engineering rigor would help software development, as if it
were some kind of second-rate branch of physics, see also http://www.semat.org. For a good
counterargument, see Glenn Vanderburg’s presentation “Software Engineering Doesn’t Work!”
at http://confreaks.net/videos/282-lsrc2010-real-software-engineering.
xiv
www.it-ebooks.info