Definition and Main Characteristics

In this blog I want to talk about using checklists as an important—and even necessary—part of the testing process. You might use a checklist to smoke test an application after a release or to regression test an application in the staging environment before release.

Let’s start with the global definition of a checklist:

A checklist is a formalized list or catalog of actions and tasks that are to be performed during a testing process

With the definition out of the way, now we can get down the the more interesting introductory details.

First, after compiling checklists for a variety of projects, I can tell you that a testing checklist needs to be tailored to the needs of a particular project. There are simply no strict requirements for the checklist – it can be either structured , ordered, or free-form. The level of detail also depends entirely on the person creating it and their needs.

Second, though there are a lot of similarities, checklists for web testing and mobile testing can differ significantly in terms of the required amount detail, as well as some other nuances. Mobile testing can often be so much more complex than web testing, that the topic of creating a good checklist for mobile testing should be a completely separate blog post. For example, with mobile testing, you have to consider things like Bluetooth, mobile internet / Wi-Fi, physical features of the phone, data synchronization, screen resolution, etc. For that reason, I focus this post primarily on checklists for web applications.

Checklist Components

Let’s try to isolate some of the main components that should be present in a checklist, and then I’ll show you a sample of a checklist for a specific project.

A checklist should:

• Contain a list of actions to be performed or sections to be checked
• Include statuses that are assigned after performing actions / checks (passed, failed, blocked, in progress)
• Be composed of independent actions—each action should not rely on the previous ones. If you do not follow this simple rule, you will accidentally be compiling test cases instead of creating a checklist. That’s a valid an useful thing to do, but it’s not what we’re talking about here.

It may surprise you to hear it, butI believe that this is where the basic components of the checklist ends.

Optionally, you may choose to provide more detailed descriptions of the actions to be performed, and then you will need to a description to each of your checklist actions. The description can capture different nuances you want to test. In order not to overload the description section, you may also choose to add a notes section to each action. What you choose to write in the notes will depend on your needs, but I will present you with some specific examples of how I use the notes in my examples below.

Customizing Your Checklist

Next you may want to customize your checklist for the needs of your project. You could specify several sections for different browsers you want to test, separate mobile and desktop testing, or specify the environment or build on which the testing was carried out.

The possibilities for customizing the checklist are almost limitless, but it’s better to keep a certain balance and remember that there is an unspoken rule among testers – it will be great if tomorrow or in a month your checklist will be opened by a completely different tester and can use it without any problems in working on a project. Often that means keeping it simple and easy to use.

Finally, you may choose to number each item with a unique number or ID. We have already decided that the actions from the list should not be performed in any specific order, but it can be helpful to have IDs if you want to be able to share information about an a problem with the team. Using a number or short ID allows you to reference the action without having to copy a large or cumbersome action name to reference the action.

Benefits of Using Checklists for Testing

Now that we have analyzed the main components of the checklist and many of the optional components, it would be logical to summarize why a checklist is so useful and why it remains a critically important part of the testing process.

1. Simplicity – a basic checklist can be created quite quickly and, if desired, does not require any additional tools (Notepad, Microsoft Office, or Google Docs are all good for this purpose)
2. Flexibility – the checklist is easily adapted to the specific needs of the project and its testing processes
3. Convenient visualization – a high-quality checklist is not overloaded with unnecessary information and any can glace at it and easily determine the general structure of the work that needs to be performed and it’s current status
4. Resue – all the pluses and features described above lead us to the fact that the checklist can be changed many times over its lifetime, and can be used and edited by different team members at the same time

A Checklist Example

Now that I’ve completed the theoretical part, it’s time to put all this knowledge into practice.

Below you have the opportunity to see a checklist created for one of my recent projects. As you review it, remember that a checklist can be tailored to the needs of a particular project. It should serve as a help for the tester(s) or other team members who want to use it, and by no means does it have to be a complex or intricate structure.

I hope that is helpful to you as you create your own testing checklists. Let me know in the comments how you create checklists or customize them.

Checklist example. Part 1.

Checklist example. Part 2.

Checklist example. Part 3.

Checklist example. Part 4.

Checklist example. Part 5.