Why I love checklists (and how to use them)

My two favourite tools for development projects, and in fact for all kinds of other projects too, are sticky notes and checklists. Both are low-tech, easy to use, and incredibly versatile and powerful.

Checklists are particularly useful for situations that are routine and complicated at the same time.

What do I mean by ‘routine and complicated at the same time’?

– Routine: all steps are known in advance and no creative problem solving is required.

– Complicated: not so routine that we can manage the situation on autopilot, without any thinking.

In what way can the process be complicated?

Perhaps there are more steps than we can easily remember; maybe they are really quite simple but we only go through this process (whatever it may be) so infrequently that we forget them from one run to the next. Or perhaps the process is quite simple and easy to remember, but so important that we want to be extra sure that we get it absolutely right every single time.

In the ReQtest dev team, we use checklists for all kinds of things.

Checklists for testing

We use checklists for testing. We have a set of checklists in our project in ReQtest that we reuse when testing new features. For example, we have one for testing features that incorporate text entry.

Whenever we add or modify a feature that allows users to enter text, we test that the feature works correctly with very long texts, very short texts, empty texts, texts that include special characters, etc etc.

Checklists for release planning

We use a checklist for release planning. Normally we have about 10 releases per year, which is frequent enough to be quite routine, but still leaves room for us to forget things.

We run this checklist whenever we decide on a release date. It simply consists of a set of events that we add to our calendars. The checklist includes steps such as “-14d: publish release news”, “-7d: publish detailed description of release”, “-5h: put up release warning for users”, etc.

Checklists for external components or frameworks

We use a checklist for upgrading third-party components in ReQtest. More and more frequently, modern software development projects rely on numerous external frameworks, libraries and components working together, and ReQtest is no exception.

To ensure that they all keep working together harmoniously, we need to keep them up to date, which means regular upgrades. A checklist helps us remember all the components that need upgrading. (And by the way, another checklist includes a step that reminds us to update that list of components at regular intervals.)

Checklist for new team members

We use a checklist for getting new hires up and running, with all the hardware, software, tools and services that they need. This way we ensure that they are productive from day one and don’t need to waste time waiting, chasing down license keys etc.

As you can see, we use checklists for the above, and a few other things too. You get the picture!

BONUS – Check out  Ulf’s checklist for test managers, and this guide to using checklists in ReQtest.

We haven’t run any scientific experiments to compare life with and without checklists, but I can still confidently say that our checklists have saved us on a number of occasions, and helped us avoid errors and mistakes. Almost every time we go through a checklist, someone goes “oh right!” because they notice a step that they would otherwise have forgotten, had the checklist not been there to support them.

What processes do you have that are routine but complicated – processes where you could avoid simple, silly mistakes with the help of a checklist? Let me know in the comments below!