Topic: Interview Questions Answers On Bug Tracking

Message

   1. What are the different types of Bugs we normally see in any of the Project? Include the severity as well.

The Life Cycle of a bug in general context is: 

Bugs are usually logged by the development team (While Unit
Testing) and also by testers (While sytem or other type of testing). 

So let me explain in terms of a tester's perspective: 

A tester finds a new defect/bug, so using a defect tracking tool logs it. 

1. Its status is 'NEW' and assigns to the respective dev team (Team lead or Manager). 
2. Th
e team lead assign's it to the team member, so the status is 'ASSIGNED TO' 

3. The developer works on the bug fixes it and re-assings to the tester for testing. Now the status is 'RE-ASSIGNED' 

4. The tester, check if the defect is fixed, if its fixed he changes the status to 'VERIFIED' 

5. If the tester has the autority (depends on the company) he can
after verifying change the status to 'FIXED'. If not the test lead can
verify it and change the status to 'fixed'. 

6. If the defect is not fixed he re-assign's the defect back to the dev team for re-fixing. 

This is the life cycle of a bug. 

1. User Interface Defects - Low

2. Boundary Related Defects - Medium

3. Error Handling Defects - Medium

4. Calculation Defects - High

5. Improper Service Levels (Control flow defects) - High

6. Interpreting Data Defects - High

7. Race Conditions (Compatibility and Intersystem defects)- High

8. Load Conditions (Memory Leakages under load) - High

9. Hardware Failures:- High

2. 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.

Author	Message
poli Senior Member Joined: 03Apr2007 Online Status: Offline Posts: 462	Topic: Interview Questions Answers On Bug Tracking Posted: 27Jun2007 at 12:30am
	1. What are the different types of Bugs we normally see in any of the Project? Include the severity as well. The Life Cycle of a bug in general context is: Bugs are usually logged by the development team (While Unit Testing) and also by testers (While sytem or other type of testing). So let me explain in terms of a tester's perspective: A tester finds a new defect/bug, so using a defect tracking tool logs it. 1. Its status is 'NEW' and assigns to the respective dev team (Team lead or Manager). 2. Th e team lead assign's it to the team member, so the status is 'ASSIGNED TO' 3. The developer works on the bug fixes it and re-assings to the tester for testing. Now the status is 'RE-ASSIGNED' 4. The tester, check if the defect is fixed, if its fixed he changes the status to 'VERIFIED' 5. If the tester has the autority (depends on the company) he can after verifying change the status to 'FIXED'. If not the test lead can verify it and change the status to 'fixed'. 6. If the defect is not fixed he re-assign's the defect back to the dev team for re-fixing. This is the life cycle of a bug. 1. User Interface Defects - Low 2. Boundary Related Defects - Medium 3. Error Handling Defects - Medium 4. Calculation Defects - High 5. Improper Service Levels (Control flow defects) - High 6. Interpreting Data Defects - High 7. Race Conditions (Compatibility and Intersystem defects)- High 8. Load Conditions (Memory Leakages under load) - High 9. Hardware Failures:- High 2. 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. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Software Testing @ OneStopTesting : Bug Report @ OneStopTesting