Checklists play an important role in testing software. But these are the most under-used tools. Using checklists effectively can save time, cost, and make testing simpler. Checklists can be accommodated in traditional test methods and in the currently popular exploratory test methods.
Motivation
Many a times while testing large applications, with thousands of fields and objects, testers feel the heat of testing, whether these fields and objects work according to the prescribed functionalities (Black box testing). An important subset of black box testing that is often overlooked is to ensure all the fields that collect information from the user, can gracefully handle any value that is entered. Even if when the developers stamp "Unit Test done 100%", testers have to responsibility to ascertain every field and object is according to specifications and can elegantly handle any value. Testing from a black box perspective generates number of tests and huge documentation. All testers are faced with time and resource limitations. Creating huge formal documentation saps the time and energy of the testers who can utilize his time and energy on finding bugs.
Applying Checklists in Testing
Since our Clients or Company Management are ever demanding, whether we follow the traditional methods or exploratory methods of testing, documentations has to be generated. Our effort is to minimize the documents generated and keep them short. If test cases were to be written for every test that has to be run, the load of creating formal test case documents will affect the tester in utilizing his time and energy in finding bugs.
At times like this, Checklists can come in handy. The checklist I advocate is Checklists made on the run, which can be used instead of writing a complete test case. I prefer to use the word 'Open Checklist.'
What is this 'Open Checklist' all about?
While testing their will always be known properties that have to be tested.
For e.g., Common errors, Properties and Functionalities of objects, Standardized Alert Messages and 'should be there' features.
Proper documentation should be created for meeting client requirements and also for regression testing.
The open checklist lists out the properties to be tested vertically and the form name and its corresponding objects horizontally. A tick mark or 'P' is to be placed if the Object and its properties match i.e., when the test is pass. A check mark or "F" is to be placed when the test fails. When the combination is not practical, an "N" can be placed.
The properties can be predetermined according to the test specifications while the Form name and the Object name can be filled while testing along with the Actual Results.
The beauty of Open Checklist is all the common objects found in the application can be accommodated in one table and can be easily traced.
Similarly, all the objects and features that are to be tested can be incorporated different checklist modified according to its on properties.
If this concept of Open Checklists, is implemented properly, can reduce the time taken for creating and executing manual test cases considerably.
An example checklist is shown below.
Figure 1 is an example checklist that can be used for testing all the 'Text boxes' that are in the application.
For testing an software, that has many text boxes, all the properties and known issues for the text box, can be tested by listing them horizontally according to the form names and the object names as used in the application.
'P' or 'F' or 'N' can then be placed according to the object meeting the specified property.
Traceability
Traceability is another important factor when lots of test cases are generated.
Traceability can be built in these kinds of checklists. The Checklist ID can be given to all the checklists based on a common naming convention. Each property can be coded for easy identification.
Here in this example Property 1 is taken as 'A', Property 2 as 'B', etc. The horizontal rows are numbered.
Naming convention can be created for each test that has been done through this checklist.
The convention can be
For e.g. a test of Property 1 on Password Text Box in form Login in the above example, the convention can be:
TB1_Login_Password_A
Practical Inference
When this method of Open Checklist was applied for an ERP product, it was found that nearly 40% of the time taken for generating and executing manual test cases was reduced.
Acknowledgement
I acknowledge God, the Almighty. Also, I thank my colleague Abraham Joseph for contributing his ideas to implement this concept.
