When problems are encountered during the testing phase of a product or application, they have to be noted so that the problem can be corrected or prevented before the next testing phase. These problems have to be noted within a form known as a List of Errors form or a Problem and Resolution form or an Incident form. For us right now, we’ll simply call it a Bug List. Any irregularities or anomalies noted within the Bug List will be passed to the development group, who will resolve the problem.
The Bug List should contain at least 5 columns. The column headings should be listed accordingly: ‘Date Bug Found’, ‘Description of Bug, ‘Resolution’, ‘Date Bug Closed ‘, and ‘Comments’. The tester will describe in extreme detail the exact steps that led up to the occurrence within the ‘Description of Bug ‘column. This part of the form is crucial for replicating an error. Without it, the developer will not be able to duplicate the error and hence correct it.
For finding bugs (problems), every test plan has to be extremely detailed and every test scenario listed. Yes, there will be times when not every case/scenario is noted. If the tester does create a unique case, this case should be noted within the bug list. This way, when the application/product goes into the next testing phase, this new test case will be added to the test plan, as well as tested.
When testing is completed, the list will be directed to the appropriate developer and Project manager involved. Every bug found should be corrected, but then there are various grades of bugs. There are quick fixes, such as spelling errors, simple fixes which involve minor programming, i.e., a value was to be added and wasn’t, medium sized fixes which take a few hours when a functionally will not work under certain conditions, serious ones which require rework, and red flag ones where the applications/product seizes to work. Depending on time constraints, the more serious ones (red) will be corrected first. Then when time allows the minor ones will finally be corrected.
Once the problem is corrected by the developer and the fix is inserted into the ‘Resolution’ column, the tester will be informed. The tester will then perform regression testing where the tester tries to recreate the error. Once the tester is satisfied that the issue is resolved, a date for closing the bug can be inserted within the ‘Date bug closed’ column, and any pertinent comments needed can be added to the ‘Comments’ column.
For more complicated testing, there are now programs that will perform automatic testing when needed for direct testing and for regression testing. These new applications are really helpful especially when repeated tests need to be done. To help you keep track of all the bugs, there are also programs out there now that will assist you in keeping track of all bugs. These tracking programs are very useful, especially when a Quality Assurance Manager needs to be on top of all Red flagged issues.
This part of the Testing phase, where time is spent on creating the Bug list, has to be taken into consideration when scheduling time within the project plan. The same goes for adding in time for correcting problems and regression testing. Without the project plan, we would not be aware of our time line or different events that have to occur from a product or applications initiation or start to its completion. But to get back to the Bug list, without it, we would not be able to communicate and keep track of all these problematic issues that need to be resolved.
Gail Zack Anderson, President of Applause, Inc., has nearly 20 years experience in training and coaching. She
provides individual presentation coaching, and leads effective presentation workshops and effective trainer workshops.
Theresa Pojuner is a Documentation Specialist with over 20 years of writing experience and is skilled in many areas of documentation, for example, Style Guides, Training Manuals and Test Cases, wth a specialty n Technical Writing and Procedures.