Top Ten Tips for Bug Tracking

  1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.
  2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed.
  3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not repro, duplicate, or by design.
  4. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.
  5. You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn't have to retest the bug on a version of the software where it wasn't even supposed to be fixed.
  6. If you're a programmer, and you're having trouble getting testers to use the bug database, just don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "please put this in the bug database. I can't keep track of emails."
  7. If you're a tester, and you're having trouble getting programmers to use the bug database, just don't tell them about bugs - put them in the database and let the database email them.
  8. If you're a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they'll get the hint.
  9. If you're a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great "unimplemented feature" database, too.
  10. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database.

For more Details and Complete Details :

http://www.joelonsoftware.com/articles/fog0000000029.html
Painless Bug Tracking


By Joel Spolsky Wednesday, November 08, 2000

  • Interview Candidate
  • 18
  • 3366

Showing Answers 1 - 18 of 18 Answers

Jordan

  • Jul 11th, 2005
 

 
nullRemember that the only person who can close a bug is the person who opened it in the first place. 
 
This may not be correct always. The Technical Authority will have the authority to assing the colsing authority to some body else.  
 

  Was this answer useful?  Yes

sendil

  • Jul 19th, 2005
 

Pls , let me know what website provided free tutorials for testing tools and how to describe the testing project

  Was this answer useful?  Yes

bicu

  • Jan 30th, 2006
 

I recommend adding small comments to the main pieces of codes and using debug messages. You can also implement a "debug mode", which can be a global variable. If that mode is enabled, the variables values will be shown in the critical places of the application. This should help tracking the variables and seing when the problem occurs. (this method can be useful when the development environment does not have a 'watch')

  Was this answer useful?  Yes

Anuva

  • Sep 7th, 2007
 

Hi,

Yes, this is true that the authorities can close a bug, but ideally the bug should be fixed by the person who has opened it. Its by the rule and exceptions are always there.

Regards,
Anuva
Infosys

  Was this answer useful?  Yes

kumarsingh

  • Apr 20th, 2009
 

1) Before logging the defect in the defect-tracking tool make sure the same
or same kind of the defect is raised before. If it raised before just add your
observation to the defect.
2) Make sure that all the stakeholders of the defects are involved in the
address list of the defect-tracking tool. Address list should be customized on
the need basis
3) Put the correct severity and priority for the defect raised
4) Grab the attention of the developers by Inform through the mails or by calls
if defect raised is of high severity and high priority (show stopper kind)
5) The person who raised the defect should take the ownership of the defect.
Tracked until the closure by the person who raised.
6) Log the defect how much ever the small issue.
7) Defect should include steps to reproduce. Once you wrote the steps to
reproduce make sure that you can reproduce yourself using the same steps.


srinivasulub1981

  • May 20th, 2009
 


 1. Before logging the issue, try to reproduce the issue twice, if still exists then log it

 2. Bug description should be neat and clean, and it should  be as simple as possible

 3. Give the proper priority, severity, and fill the remaining fields like type of testing,
     page name, etc...

 4. Use proper screen shots to refer the isues

 5. Give the proper expected behaviour, actual behaviour

 6.  Verify whether the issue is already raised by some body else, if raised and closed,
       then re-open again


Srinivas

 7.  

preethi.gollamandala

  • Sep 9th, 2009
 

Tester should be able to reproduce the bug
bug description should be understadable to everyone
we should assign proper  priority & severity to the reported bug
we should attach proper screen shots to the reported report
always status of the bug should be uptodate.
All the bugs information should exists in the bug tracking tool.

regards
preethi.g


kurtz182

  • Dec 30th, 2009
 

Top twelve tips for initial bug reporting:

1) Ensure you can reproduce the defect before entering defect report
2) Ensure there are no duplicates before entering defect report
3) Include all relevant details in the title of your report while keeping it short
4) Include details about the environment in which the defect was discovered
5) Include all of the steps to reproduce the issue in your defect report
6) Clearly define how the actual result differs from your expectation
7) Author a clear and concise report that repects your audience's time
8) Provide only the facts and not your opinions
9) Ensure nothing about your report is misleading
10) Include all necessary supporting documentation in your defect report
11) Ensure your severity and priority assignments align with company standards
12) Bring urgent issues to the attention of key stakeholders
 

Top twelve tips for bug tracking and subsequent communication:

1) Check daily for defects reports that are assigned to you
2) When defects are assigned to you, handle them immediately
3) Close defect reports immediately when issues are resolved
4) Always enter a comment that describes what you did to justify defect closure
5) Determine whether regression tests are warranted upon closing defects
6) Assign defects immediately to those who can facilitate progress on issues
7) When issues are returned for reasons you don't agree with, tell a compelling story
8) Remember that it is your job to report issues and not resolve them
9) Use common sense and good judgment
10) Balance customer advocacy with business needs
11) Keep communcation professional; do not appear to be argumentative
12) Get someone else involved if you can't reach an agreement on an important issue

  Was this answer useful?  Yes

Give your answer:

If you think the above answer is not correct, Please select a reason and add your answer below.

 

Related Answered Questions

 

Related Open Questions