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)