|
When submitting bugs make sure that you are proving
enough details so that development doesn't have to come looking for you to get them. If the problem is specific
to particular areas such as: client site, admin, server or database try to provide information that is specific
to them, for instance if this area is client - what kind of platform application is running on: Win95, WinNT, UNIX,
if it is a database what kind of database: Oracle, Informix, Sybase. Also, whenever possible attach log files and
point out the errors in your bug report. Do not just submit a bug that something is just not working.
If you are not sure why something is failing try to get some help from someone in QA or in Development. When you
are verifying bugs be careful about kicking bugs back. If the original issue stated in the bug is fixed and you
find a different problem you should close out the original bug and open a new one. It makes it much easier to track
issues.
Software application has many modules with different
functionalities so while logging bug if you specify in which module the bug is. This will be helpful for Production/R&D
to identify area of bug. Also helpful to analyse the module which has maximum bugs
While Submitting Bugs , it should have some mandatory Fields like "Title", "Bug Description"
and "Steps to reproduce the Bugs". It will be good if there is Sweep also. From Development point of
view Steps to reproduce is very important. Important point is not only to find the Bugs but to "GET SOLVED".
Also the Severity of the Bugs should be there?? Like Critical, serious,Minor, Workable. Some Bug Tracking Tool
should be used for tracking the Bugs. Also Bug Report Review Should happen.
Seeing is believing: Screen captures can be great help in motivating developers to fix bugs that are hard to recreate.
For extra-elusive bugs, that demand strange sequences of steps, consider connecting a VCR to your TV out port and
recording your session for the astonished developers (useful tip from "Software Testing").
|
