Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration(Net Objectives Lean-Agile Series)

Praise for Lean-Agile Acceptance Test-Driven Development   “Lean-Agile Acceptance Test-Driven Development tells a tale about three fictive project stakeholders as they use agile techniques to plan and execute their project. The format works well for the book; this book is easy to read, easy to understand, and easy to apply.” —Johannes Brodwall, Chief Scientist, Steria Norway   “Agile development, some say, is all about pairing, and, yes, I’m a believer in the power of pairing. After reading this book, however, I became a fan of the ‘triad’—the customer or business analyst + the developer + the tester, who work collaboratively on acceptance tests to drive software development. I’ve written some patterns for customer interaction and some patterns for testing and I like what Ken Pugh has chosen to share with his readers in this down-to-earth, easy-to-read book. It’s a book full of stories, real case studies, and his own good experience. Wisdom worth reading!” —Linda Rising, Coauthor of Fearless Change: Patterns for Introducing New Ideas   “The Agile Manifesto, Extreme Programming, User Stories, and Test-Driven Development have enabled tremendous gains in software development; however, they’re not enough. The question now becomes ‘How can I ensure clear requirements, correct implementation, complete test coverage, and more importantly, customer satisfaction and acceptance?’ The missing link is acceptance as defined by the customer in their own domain language. Lean-Agile Acceptance Test-Driven Development is the answer.” —Bob Bogetti, Lead Systems Designer, Baxter Healthcare   “Ken Pugh’s Lean-Agile Acceptance Test-Driven Development shows you how to integrate essential requirements thinking, user acceptance tests and sounds, and lean-agile practices, so you can deliver product requirements correctly and efficiently. Ken’s book shows you how table-driven specification, intertwined with requirements modeling, drives out acceptance criteria. Lean-Agile Acceptance Test-Driven Development is an essential guide for lean-agile team members to define clear, unambiguous requirements while also validating needs with acceptance tests.” —Ellen Gottesdiener, EBG Consulting, www.ebgconsulting.com, Author of Requirements by Collaboration and The Software Requirements Memory Jogger   “If you are serious about giving Agile Testing a chance and only have time to read one book, read this one.” —David Vydra, http://testdriven.com   “This book provides clear, straightforward guidance on how to use business-facing tests to drive software development. I’m excited about the excellent information in this book. It’s a great combination of the author’s experiences, references to other experts and research, and an example project that covers many angles of ATDD. A wide range of readers will learn a lot that they can put to use, whether they work on projects that call themselves lean or agile or simply want to deliver the best possible software product.” —Lisa Crispin, Agile Tester, ePlan Services, Inc., Author of Agile Testing   Within the framework of Acceptance Test-Driven-Development (ATDD), customers, developers, and testers collaborate to create acceptance tests that thoroughly describe how software should work from the customer’s viewpoint. By tightening the links between customers and agile teams, ATDD can significantly improve both software quality and developer productivity.   This is the first start-to-finish, real-world guide to ATDD for every agile project participant. Leading agile consultant Ken Pugh begins with a dialogue among a customer, developer, and tester, explaining the “what, why, where, when, and how” of ATDD and illuminating the experience of participating in it.   Next, Pugh presents a practical, complete reference to each facet of ATDD, from creating simple tests to evaluating their results. He concludes with five diverse case studies, each identifying a realistic set of problems and challenges with proven solutions.   Coverage includes   •     How to develop software with fully testable requirements •     How to simplify and componentize tests and use them to identify missing logic •     How to test user interfaces, service implementations, and other tricky elements of a software system •     How to identify requirements that are best handled outside software •     How to present test results, evaluate them, and use them to assess a project’s overall progress •     How to build acceptance tests that are mutually beneficial for development organizations and customers •     How to scale ATDD to large projects  

Table of Contents:
Introduction 1 Part I: The Tale Chapter 1: Prologue 9 Ways to Develop Software 9 One Way 9 Another Way 9 The Difference 10 The Importance of Acceptance Tests 10 System and Team Introduction 12 The System 12 The People 13 Summary 14 Chapter 2: Lean and Agile 15 The Triad and Its Units 15 Post-Implementation Tests 17 Quick Feedback Better Than Slow Feedback 18 Preimplementation Tests 19 Lean and Agile Principles 20 Summary 21 Chapter 3: Testing Strategy 23 Types of Tests 23 Where Tests Run 25 Test Facets 26 Control and Observation Points 27 New Test Is a New Requirement 27 Summary 28 Chapter 4: An Introductory Acceptance Test 29 A Sample Business Rule 29 Implementing the Acceptance Tests 31 Test Script 32 Test User Interface 33 xUnit Test 34 Automated Acceptance Test 35 An Overall Test 36 Testing Process 37 Summary 37 Chapter 5: The Example Project 39 The Charter 39 Objectives 40 Project Acceptance Tests 41 High-Level Requirements 43 Features 43 Feature Acceptance Criteria 45 Summary 46 Chapter 6: The User Story Technique 47 Stories 47 Features into Stories 48 Roles 49 Role Attributes 49 Persona 50 Stories for Roles 51 Story Acceptance Criteria 52 Acceptance Tests Determine Size 53 Customer Terms 54 INVEST Criteria 55 Summary 56 Chapter 7: Collaborating on Scenarios 57 Use Cases from User Stories 57 Simple Use Case 59 Exceptions and Alternatives 60 Acceptance Tests 63 Documentation 63 Story Map 63 Conceptual Flow 65 Communication 66 Summary 68 Chapter 8: Test Anatomy 69 Triad Creates Tests 69 Test Context 70 Test Structure 71 Calculation Table 73 Data Table 74 Action Table 75 Tests with Example Values 76 Requirements Revised 77 Acceptance Test Revised 78 Test with Values in Text 79 When and Where Tests Are Run 80 Summary 81 Chapter 9: Scenario Tests 83 Tests for Exception Scenarios 83 Tests for Business Rules 87 Cross-Story Issues 88 Don’t Automate Everything 89 Multi-Level Tests 90 User Interface Tests 93 Check the Objectives 93 Summary 94 Chapter 10: User Story Breakup 95 Acceptance Tests Help Break Up Stories 95 Business Rule Tests 96 A Story with a Business Rule 100 Summary 101 Chapter 11: System Boundary 103 External Interfaces 103 More Details 107 External Interface Tests 108 Component Tests 108 Test Doubles and Mocks 111 What Is Real? 112 Story Map of Activities 113 Summary 114 Chapter 12: Development Review 115 The Rest of the Story 115 Usability Testing 116 Separating State from Display 116 Quality Attribute Tests 118 Workflow Tests 119 Deployment Plans 120 From Charter to Deliverable 120 Summary 121 Part II: Details Chapter 13: Simplification by Separation 125 Complex Business Rules 125 Simplify by Separating 126 The Simplified Rule 128 Rental History 128 Summary 130 Chapter 14: Separate View from Model 131 Decouple the User Interface 131 Decoupling Simplifies Testing 136 Summary 136 Chapter 15: Events, Responses, and States 137 Events and an Event Table 137 States and State Transitions 139 Internal State or External Response 142 Transient or Persistent States 144 A Zen Question 144 Summary 144 Chapter 16: Developer Acceptance Tests 145 Component Acceptance Tests 145 Field Display Tests 145 Tabular Display Tests 147 Summary 151 Chapter 17: Decouple with Interfaces 153 Tests for a Service Provider 153 The Interface 153 Quality Attribute Tests 155 Comparing Implementations 155 Separating User Interface from Service 157 Separation of Concerns 158 Reusable Business Rules 158 Summary 159 Chapter 18: Entities and Relationships 161 Relationships 161 Entities and Relationships 161 Multiple Relationships 163 Alternative Representations 166 Summary 166 Chapter 19: Triads for Large Systems 167 Large Systems 167 When a Customer Test May Not Be Required 169 Data Conversion 170 Database Conversions 170 What If There Are No Tests? 170 Legacy Systems 172 Summary 173 Part III : General Issues Chapter 20: Business Capabilities, Rules, and Value 177 Business Capabilities 177 Scenario Handling 178 Business Rules Exposed 179 A Different Business Value 179 Summary 181 Chapter 21: Test Presentation 183 Customer Understood Tables 183 Table Versus Text 185 Specifying Multiple Actions 185 Complex Data 187 Custom Table Forms 188 Summary 189 Chapter 22: Test Evaluation 191 Test Facets 191 Understandable to Customers 191 Spell Checked 192 Idempotent 192 Not Fragile 192 Test Sequence 193 Workflow Tests 193 Test Conditions 194 Separation of Concerns 194 Test Failure 195 Test Redundancy 196 No Implementation Issues 197 Points to Remember 197 Summary 198 Chapter 23: Using Tests for Other Things 199 Uses of Acceptance Tests 199 Degree of Doneness 199 Estimation Aid 200 Breaking Down Stories 200 Developer Stories 200 Tests as a Bug Report 201 Root Cause Analysis 201 Production Bugs 202 Regression Testing 202 Summary 202 Chapter 24: Context and Domain Language 205 Ubiquitous Language 205 Two Domains 207 Summary 208 Chapter 25: Retrospective and Perspective 209 Recap 209 The Process 210 Testing Layers 210 The Tests 211 Communication 212 What’s the Block? 212 Monad 212 Unavailable Customer 213 Change 213 Risks 214 Benefits 214 Summary 215 Part IV Case Studies Chapter 26: Case Study: Retirement Contributions 219 Context 219 The Main Course Test 220 Setup 220 Event 221 Expected 221 Implementation Issues 222 Separation of Concerns 222 Business Value Tracking 223 One Exception 223 Event 223 Expected 224 Another Exception 225 Event 225 Expected 225 Two Simultaneous Exceptions 226 Event 226 Expected 227 The Big Picture 227 Event Table 228 State Transition Table 228 Summary 230 Chapter 27: Case Study: Signal Processing 231 It’s Too Loud 231 Sound Levels 231 Developer Tests 233 Summary 233 Chapter 28: Case Study: A Library Print Server 235 The Context 235 A Workflow Test 236 Summary 241 Chapter 29: Case Study: Highly Available Platform 243 Context for Switching Servers 243 Test for Switching Servers 244 Test for Technical Rule 246 Summary 248 Part V : Technical Topics Chapter 30: How Does What You Do Fit with ATDD? 251 Test Platforms 251 Internal Design from Tests 252 Device Testing 254 Starting with User Interfaces 255 Black Box Testing 255 Unit Testing 256 Summary 256 Chapter 31: Test Setup 257 A Common Setup 257 Some Amelioration 259 Test Order 260 Persistent Storage Issues 260 Summary 261 Chapter 32: Case Study: E-Mail Addresses 263 Context 263 Breaking Down Tests 264 Local-Part Validation 265 Domain Tests 266 Disallowed Domain Tests 268 Test to Ensure Connection 269 Verification Test 269 Summary 270 Part VI : Appendices Appendix A: Other Issues 273 Context 273 Customer Examples 274 Fuzzy Acceptance Tests 274 Acceptance Test Detail 275 Requirements and Acceptance Tests 275 Documenting Requirements and Tests 276 Decoupling Requirements 276 Separation of Issues 276 Testing Systems with Random Events 277 The Power of Three 277 Summary 278 Appendix B: Estimating Business Value 279 Business Value 279 Developer Stories 281 Summary 282 Appendix C: Test Framework Examples 283 The Examples 283 Fit Implementation 284 Setup 284 Check-Out CD 284 Check-In 286 Category-Based Rental Fees 287 Slim–Table Style 288 Header 288 Setup 288 Check-Out CD 288 Check-In 290 Category-Based Rental Fees 291 Slim–Cucumber Style 291 Setup 291 Check-Out CD 292 Check-In CD 292 Scenario Library 292 Category-Based Rental Fees 294 Robot 295 Setup 295 Check-Out CD 295 Check-In CD 296 Category-Based Rental Fees 296 Cucumber 296 Check-Out CD 297 Check-In CD 297 Category-Based Rental Fees 297 Test Frameworks 298 Summary 298 Appendix D: Tables Everywhere 299 User Interface Tests with Tables 299 Requirement Tables 301 Another Table 302 Quality Attribute Requirements 303 Data Tables 304 Summary 304 Appendix E: Money with ATDD 305 The Context 305 The Original Tests 306 The Acceptance Test Approach 307 Summary 310 Appendix F: Exercises 311 Calculator 311 Create Some Tests 313 More Exercises 313 Sam’s CD Rental 314 Triangle 314 File Copying Exercise 314 References 315 Epilogue 323 Index 333

About the Author :
Kenneth Pugh has over two-fifths of a century of software experience. Previously a principal at Pugh-Killeen Associates, he is now a fellow consultant for Net Objectives. He has developed software applications ranging from radar tracking to financial analysis. Responsibilities have included everything from gathering requirements to testing. After the start of the new millennium, he has worked with teams to create software more effectively with lean and agile processes. He has spoken at numerous national conferences; consulted and taught all over the world; and testified on technology topics. This is his seventh book. In 2006, his book Prefactoring won the Jolt Award [DrDobbs01]. In his spare time, he snowboards, windsurfs, and backpacks. Between 1997 and 2003, he completed the Appalachian Trail. The cover photograph of Mount Katahdin, the northern end of the trail, was taken by the author from Abol Bridge in Maine.

Review :
Praise for Lean-Agile Acceptance Test-Driven Development   “Lean-Agile Acceptance Test-Driven Development tells a tale about three fictive project stakeholders as they use agile techniques to plan and execute their project. The format works well for the book; this book is easy to read, easy to understand, and easy to apply.” –Johannes Brodwall, Chief Scientist, Steria Norway   “Agile development, some say, is all about pairing, and, yes, I’m a believer in the power of pairing. After reading this book, however, I became a fan of the ‘triad’–the customer or business analyst + the developer + the tester, who work collaboratively on acceptance tests to drive software development. I’ve written some patterns for customer interaction and some patterns for testing and I like what Ken Pugh has chosen to share with his readers in this down-to-earth, easy-to-read book. It’s a book full of stories, real case studies, and his own good experience. Wisdom worth reading!” –Linda Rising, Coauthor of Fearless Change: Patterns for Introducing New Ideas   “The Agile Manifesto, Extreme Programming, User Stories, and Test-Driven Development have enabled tremendous gains in software development; however, they’re not enough. The question now becomes ‘How can I ensure clear requirements, correct implementation, complete test coverage, and more importantly, customer satisfaction and acceptance?’ The missing link is acceptance as defined by the customer in their own domain language. Lean-Agile Acceptance Test-Driven Development is the answer.” –Bob Bogetti, Lead Systems Designer, Baxter Healthcare   “Ken Pugh’s Lean-Agile Acceptance Test-Driven Development shows you how to integrate essential requirements thinking, user acceptance tests and sounds, and lean-agile practices, so you can deliver product requirements correctly and efficiently. Ken’s book shows you how table-driven specification, intertwined with requirements modeling, drives out acceptance criteria. Lean-Agile Acceptance Test-Driven Development is an essential guide for lean-agile team members to define clear, unambiguous requirements while also validating needs with acceptance tests.” –Ellen Gottesdiener, EBG Consulting, www.ebgconsulting.com, Author of Requirements by Collaboration and The Software Requirements Memory Jogger   “If you are serious about giving Agile Testing a chance and only have time to read one book, read this one.” –David Vydra, http://testdriven.com   “This book provides clear, straightforward guidance on how to use business-facing tests to drive software development. I’m excited about the excellent information in this book. It’s a great combination of the author’s experiences, references to other experts and research, and an example project that covers many angles of ATDD. A wide range of readers will learn a lot that they can put to use, whether they work on projects that call themselves lean or agile or simply want to deliver the best possible software product.” –Lisa Crispin, Agile Tester, ePlan Services, Inc., Author of Agile Testing