What's your bug management process?

Question

Hi All,

What is the lifecycle / process of a bug? Speaking generally, Are there any tips, suggestion process wise that bug fixing should go though?

Answer 1

Test (the software) -> Log (the bug) -> Fix -> Verify -> Close

Answer 2

1. User Reports Bug
2. QA reproduces bug
3. A Dev triages the bug to verify whether it's a bug or a new feature request
4. If it's a bug, it's assigned to a dev
5. QA tests the bug fix in the next release
6. Release

Answer 3

1. Notice the bug.
2. Find the bug, be able to reproduce it.
3. Code solution, fix the bug.
4. Testing - prove you have fixed the bug and not introduced new bugs (functionality and unit tests).
5. Redeploy or patch.

Simple question, simple answer. Hope this helps.

Answer 4

A good book on the subject is:

Debugging by David J. Agans

One of which is to use a rifle and not a shotgun approach when debugging. That is to be sure to test each piece to find the problem. In addition, once you make a fix then try to break it again to make sure you understand what went wrong.

There has been times when I made a fix (in maintenance code) only to discover that the fix broke other things. Before you mark a bug as fixed ensure that the fix does not break something else.

Which brings up the real issue of a bug: Failure to completely understand what the code is doing.

Answer 5

When I find a bug, the first thing I do is log it in the bug system. Then I write the test to illustrate the bug, then fix the code to make sure the test passes. This ensures that you can a) reproduce the bug and b) fix the bug.

Periodically, I will do some analysis on the bug database to figure out why the bugs are occurring. Are there errors in the spec, logic errors in the code, etc? And take the appropriate measures to reduce the bug counts.

I've detailed this in my blog http://jeffastorey.blogspot.com/2010/02/what-to-do-when-you-find-bug.html here.

Answer 6

A few things beyond the standard Find->Fix->Test-Release cycle:

• A bug should have multiple assignments, so it can be assigned to one person for fixing, and another person for testing it, instead of being assigned to a single person.

• Your bug track system must track all history of what was changed.

• Keep track of what version a bug was found in, was fixed in, was tested in, and then was released in. They are all different and important values.

• Have the ability to change an issue from a bug to an enhancement.

• Have a status for "question" or "waiting for answers", to represent questions have been sent to a business analyst, essentially blocking progress on the bug.

• Keep a bug restricted to a single issue, so that you can verify whether that issue is acutally fixed. So if there are 3 things wrong with a screen, log 3 bugs, instead a single of "Issues on the Whatever Screen"; these bugs may be fixed and released individually, and you need to be able to track that.

Answer 7

My organizations have followed this pattern:

1. Systems engineer or QA notices the bug and enters it in the bug tracking tool.

2. PM or Dev Lead prioritizes the bug according to severity, possible workaround, and the effort required to fix it.

3. PM or Dev Lead assigns the bug to a developer.

4. Developer reproduces the bug, with any necessary help from the person in step 1.

5. Developer codes a solution and makes a build (or has a build made).

6. Tester from step 1 retests the bug.

7. If the bug is fixed, redeploy or patch. Else, repeat steps 5 and 6 until it is fixed or a more pressing issue takes priority.

8. If the bug was found by the customer, verify with them that it is fixed.

Generally, bugs go through this assignment cycle: Tester -> (PM/Lead, then developer; or developer) -> Tester -> PM/Lead -> Closed.

Answer 8

I can't help getting snarky here. I tried but finally broke down. The real bug process:

User emails developer to fix bug. Developers emails back and says can't work on it unless entered into the Project management system. Everybody hates the PM system so user whines about having to enter it. Dev stands firm as he needs somewhere to charge his time. Bug entered into system and assigned to a differnent developer.

There are three branches from here:

Branch 1, dev looks at screen shot provided and notices that user is looking for 2010 data on 2009 reporting page. User informed of error and bug closed.

Dev agrees that the system definitely does not work the way the user wants it to. However it does work the way the spec defined it. User does not want to hear that this is now a development job and not a bug. User especially distressed when he will have to tell the client that since this is new work, he will have to pay extra. Decision made to treat it like a bug anyway to make the client happy and bug is fixed and closed. Later management wonders why the system is so buggy and we are losing money on development.

Oh my, there really is an actual bug, dev fixes and moves fix to prod and closes bug.