Don’t forget the checklist
I recently read The Checklist Manifesto: How To Get Things Right by Atul Gawande. This is yet another book not about testing that testers should read. Gawande is a surgeon and relates his experiences from the field of medicine throughout the book. )ne of the first chapters goes into depth on the growing complexity and body of knowledge in medicine, and how difficult it is to keep many of the important details of the practice in mind consistently. Sound Familiar?
In Gawande’s experiments, he looked at areas where there were “bugs” (“bugs” in his case were complications or death), and created short, simple checklists that could be used by the medical staff to reduce risk – and the checklists worked wonderfully – fore example, reducing infection in central line procedures by over 60%. He also points out the cause of error (I’m a huge fan of Reason’s Human Error) usually breaks down to errors of ignorance (not knowing the right thing to do), and errors of ineptitude (not knowing how to apply what we know).
Checklists aren’t new to testing. Kaner talks about checklists, and testers at Microsoft have been using “am I done” type checklists for at least 15 years (Michael Hunter has a great list here). Checklists are good tools for testers to use and probably worth looking at more closely.
But building a checklist is probably harder than you think. In my experience (Gawande saw the same thing), most checklists are too long and contain too much detail. They get in the way! To make matters worse, as you learn more, you will likely add additional items to your checklist. The solution is simple enough – start with the smallest possible checklist you think you can get away with (and then see if there’s anything else you can remove). Realize that your checklist can change over time as you learn more about your processes and the types of errors your team makes. Try it – I think you’ll find that checklists are a great help.
Remember - don’t forget to use a checklist (you can always use another checklist as a reminder)
“The Checklist Manifesto: How To Get Things Right” is now on my Amazon wish-list. Thanks for the tip…
And I added “Human Error” by James Reason to mine!
I initially started using QA checklists after reading about significantly reduced error rates in hospitals after simple checklists were introduced. A high level of training should not make one feel too proud to (alertly) follow steps on a piece of paper.
What I find interesting, as you say, is what to include in these checklists. Do you keep it high level for each area, or get into small specific checklists for each particular area. For example, in the book, he talks about Pilots a lot and how there are checklists for different types of scenarios (bugs) that may occur. At that point there is a short succinct checklist for the pilots to go through.
So as a tester, should we develop checklists for all types of scenarios — i.e. if you run across this type of bug, have a context specific checklist that will get the tester to go through some quick checks.
We use checklists, but after reading this book they can most certainly be improved upon. Probably generated differently as well. I’d love to see/chat with other testers on how they are using Checklists as described by Gawande.
We let the checklists morph over time. For example, when we started we had one checklist, but now the checklists for reviewing c# and c++ code are quite different.
But, the checklist for code review is /completely/ different than a checklist for something like globalization testing (an area where we sometimes use checklists). I haven’t tried it extensively across all testing tasks, but given Gawande’s research and our own findings, I’d imagine that a booklet of scenario specific checklists would be beneficial for a test team.