Ask yourself these questions:
- 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.
- 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.
- 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.
- Record repetitive bugs from development mistakes. A development team makes repeated mistakes across projects. Record common weak areas pertaining to development across multiple projects.
- 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.
You will be surprised at the number you managed to gather by the end of week-one.