Acceptance Tests and Final Walk Through

August 24, 2011 — Posted by Ken Pugh

Payson Hall, a friend of mine who is in project management consulting, wrote to me recently about a huge system he was reviewing. The project was having difficulty in delivery. The client had paid big bucks for this system and it was about to enter acceptance testing.

To help non-technical people on the project understand what acceptance testing was, my friend explained it was like the final walkthrough of a building before the last check is signed. He said,

"Imagine acceptance testing is like the final inspection of a building. It won't tell you whether the materials behind the wall board are good quality or bad, whether the plumbing leaks, or whether or not the wiring is up to standard."

It is a helpful metaphor for acceptance testing in software. In software, the acceptance test-driven development (ATDD) is about writing the acceptance tests before you start implementation. The implementers test the software against the acceptance tests before passing it along for full scale testing. It's all about externally visible effects: Given this input, did this output occur or did this state change?

To continue with his metaphor, the acceptance tests would be:

  • Put a full load on the outlets and see if there is any voltage drop (to see whether the wiring is sufficient). Run the load for a while and see if anything heats up. Put more than full load on the outlets and see if the circuit breakers pop.
  • Turn off all faucets and then send high pressure water into the system. If it can go in, then there is a leak somewhere.
  • Put a heat source on the outside walls and measure the inside wall temperature. This will tell whether the insulation is sufficient.
  • Put a noise source in a room. Close the doors. Measure how loud it is in the next room. This measures the inner insulation.
  • Put a weight in the center of a room and measure the deflection. This says whether the floor joists are sufficient. Do the same on the roof.

Notice that each of these acceptance tests is related to a user understandable requirement (electric capacity, water leakage, thermal, sound insulation, framing). They do not force a particular implementation - you can use copper or aluminum wire - as long as it meets the external requirement. And they can be done after the building is complete.

These tests can show defects – for example, there is a leak – but they cannot identify the specific point of the leak. They do not guarantee that the components inside are of a particular quality. But if they pass, then the components are of sufficient quality. Unless there are intermediate inspections to ensure that material is being installed correctly, you cannot confirm that good practices were used in installing them. Sheetrock can hide a lot of defects, which is why they have several inspections of a building, not just the final one.

Building codes and standards represent pre-determined means for meeting external requirements. Use this much insulation. Use this size wire. Use these size beams. The codes eliminate much of the need for creating external acceptance tests, since the tests are represented by the specified implementation.

Acceptance tests should be created ahead of time. They define what the final product should do. With software, you can always inspect the interior. But if you test along the way, using the acceptance tests, you can avoid winding up with a mess of defects.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban