Ten essentials for tracking bugs

  1. The first and foremost characteristic of a good tester is that he minimizes the number of steps needed to reproduce the bugs. This saves time for developers significantly when they have to locate the bug.
  2. It is important to keep in mind that the only person who can verify whether the bug is closed or not is the person who encountered it in the first place. Other people can resolve it. But the only one who can establish that whatever was wrong is not fixed is the one who first saw it.
  3. A bug can be resolved in numerous ways e.g. it can be termed as fixed, postponed, by design or not reproducible.
  4. Not reproducible is for the bugs for which the repro steps are not defined in the bug report. The programmers use this term to specify missing information regarding the bug in the report.
  5. It is important to always be aware of the versions in question. You have to keep in mind that whenever a software build is handed over to the testers, it should be adequately numbered so that the tester knows which version he is supposed to be testing a bug on.
  6. If your situation is such that the testers are not making use of a bug database to get bug reports to you i.e. the programmer, you have to make sure that these alternate reports are not accepted. For example if they send you emails about bug reports, all you have to do is respond back to them that they have to enter the data into the bug database as you cannot keep track of any alternate channels.
  7. If your situation is such that the programmers are just not using the bug database and always looking for alternate channels of reporting, the solution is very simple, all you have to do is NOT inform them about the bugs. Just enter your data into the database and leave it up to the database to inform the programmers through the proper channel.
  8. If your situation is such that only a limited number of fellow colleagues are using the database, it is up to you to take the initiative of bug assigning through the database. Gradually they’ll come to accept it as a norm.
  9. If your situation is such that you’re in a managerial position and neither the programmers nor the testers are making use of the bug database that you introduced, what you have to do is just use bugs and assign new features to the people. An “unimplemented feature” database can also be achieved using a bug database.
  10. It should be kept in mind that whenever you have the urge to implement additional fields in the bug database, you need to ignore it. The reason for avoiding these ideas is that with every addition, the bug database becomes less usable and once it reaches to the point where entering a bug is just too much work, people will automatically start looking for alternate ways instead of using the now complex bug database.