• How often do you browse the Internet in order to find a perfect checklist for your testing requirements?
• How often do you wish that someone somewhere in the world had prepared a checklist that you could directly apply to testing your product?
• How often do you get disappointed that all the checklists floating on the web are either inadequate or nonextensive?
• How often did you wish that you had recorded repeatable test skills from your previous projects that could be used over and over again for similar projects?

If your answer to these questions is ALWAYS, then it’s time you thought about preparing your own testing checklist.

All of us in the testing business would fairly agree to the advantages of checklist-driven testing. Checklists are handy tools, which not only eliminate the probabilities of missing, important, and repeated tests, but also help systematizing the tester’s job. Moreover, checklists are lifesavers when you use a prerelease checklist, because your company intends to make release in haste. Checklists add value to testing in more ways than you can actually think of until you use them.

Why is a tailor-made checklist better?
While testing, you not only work with the software, but also with people, procedures, and other managerial aspects related to a specific organization. This probably answers why a checklist made in some other organization may not suit completely to your testing needs.

You know the mistakes your developers are apt to make. You know the tests your testers may forget. You know the ingenious ideas implemented to discover critical bugs. If you make a checklist by considering these attributes, you may end up making a very usable and helpful checklist.

Building custom checklists
Building a checklist is not that difficult. Here are some simple steps to help testers start creating their own customized checklist.

Step 1—Start Gathering
The first step towards building a checklist is to gather testing tricks as you find them. Start with your current project. Make a simple worksheet, where you will record the initial points. Make two columns, one for numbering and second for describing the point.

You are ready to start!

For every bug that you file, scrutinize your own activity. Analyze whether the bug is an irrelevant program error, or a substantive one. Just to make sure that you don’t end up making too many unnecessary entries, here are few checkpoints.

1. Record Tricky Actions. If you invested on some innovative ideas to discover a bug, make sure you record it. Don’t let it go unnoticed; otherwise, you may forget to apply these tricky techniques elsewhere in future.
2. Record apt-to-forget tests. Many simple points that you intend to check, but forget every time because they are too simple to remember. How often do you remember to check tab sequence in a form? But every time you remember to test it, you can almost guarantee a disorder.
3. Record repetitive bugs from development mistakes. A development team makes repeated mistakes across projects. Record common weak areas pertaining to development across multiple projects.
4. Record accidental bugs. There will be bugs in the software, which you come across accidentally. You may have never thought about ways to discover those bugs, but luckily you found them while exploring through the software. Make sure that such bugs make an entry to your checklist. While testing a desktop-software, we accidentally discovered that changing the PC time zone results in garbage data in most date/time fields. Now it’s a must test criteria for every desktop software that we test.

Step 2—Classify points
Once you have gathered a decent number of points for you checklist, the next immediate step should be to organize them.

1. Generic and Specific tests. The first classification should be to separate out generic tests from program-specific ones. Few bugs seem to be typical and specific to the project. Few have probabilities of appearing in other programs too. The generic checklist will be more significant across projects. But, do not throw away the specific tests. You may consider making program-specific checklists out of those.
2. Functional Grouping. Group the points based on their functional similarities and label them under different sections, e.g. for a web application checklist you could have following sections:
   1. Session Management
   2. User State Management
   3. Accessibility
   4. Usability
   5. Web page and data validation
   6. Performance
   7. UI (Broken links and page navigation etc.)
   8. Browser Compatibility
   9. Server Testing (Load, CPU/RAM Usage)
   10. Access Channel (Dial Up, Dedicated Connection)

Classification will make referencing easy. Also, when you add more points, you can directly place them under specific groups.

Step 3—Eliminate
The next step should be to cut down on simpler, redundant, and unimportant entries. A checklist is effective when it’s focused, substantive, and brief.

The first two steps may result in too many entries in the checklist. You may not find it very sensible to collect entries first and then follow an elimination procedure. You would rather not enter these points in the first place.

It’s suggested that you think about elimination, but only after you have completed the first two steps. If you start eliminating from day-one, you may end up ignoring a lot of important tests. Also, it’s easy to make a choice from a bigger set of tests as it helps to identify important and high-priority tests over simpler ones.

Step 4—Review, Evaluate, Optimize
The checklist is most effective when it’s short and comprehensive; yet easily understandable and wide-ranging. Here’s how the checklist can be optimized towards perfection.

1. Understandable. Get your checklist verified by other testers. Check whether it is difficult for others to follow and implement tests directly from the list. All entries should be short and self-explanatory so they can be easily pursued by other testers.
2. Look outside your organization. Refer to similar checklists created by others. The Internet is a good resource for referencing other works. Pick up tricky thoughts and missed points from such checklists. This can help ensure you have a comprehensive checklist.

1. Checklist should be evolving.Good checklists don’t happen overnight. Or, if they did, we bet they wouldn’t be usable. Good checklists evolve from practical experience: they grow with time, with each project, and with more and more testing. Checklists mature and grow robust when there is serious implementation across projects.
2. Checklists should be small.Keep an eye on the size. An overloaded checklist not only prevents testers from applying them, but also creates an illusive impression of being too theoretical. Keep them minimal and record important entries to make the checklist practical and usable.
3. Add to your work routine.In your daily testing schedule, make notes of points that can enter the checklist. Update the points in the checklist at regular intervals. Similarly, application of the checklist should happen on a regular basis. This helps to check practical usage of checklist points and to get rid of ambiguous and unnecessary entries. You can ensure an up-to-date checklist by enforcing regular usage and updates.