Tuesday, February 2, 2010

What to do when you find a bug

Inevitably you will find bugs in your code (yes, even you will write bugs). Once a bug has been identified, what steps do you take to fix it? Regardless of how small the bug is, it should be put into a bug tracking system (you do have one, right? If not, consider something free like Trac). This allows you to track bugs over time and do some deeper analysis.

Once the bug is identified, take steps to reproduce the bug by writing a test that exercises the bug. Then make the code change to fix the bug. Now you've fixed it and have a test to ensure it doesn't happen again.

This is where too many people stop. It is important to identify why the bug occurred. Was it an error in specifications? An error in coding logic? or some other error? Note this in the tracking system.

Periodically, query the bug tracking system to get an idea of why these bugs are happening (root cause analysis) and take the organizational steps necessary to correct them.


  1. Thanks for the post. Your explanation steps to solve the bug is nice.

    Iphone Application Development India

  2. What suggestions do you offer for maintaining visibility of bugs and encouraging time to be set aside to work on their solutions (particularly for non-critical bugs, so that they don't just get logged and left there).

  3. Bugs, both critical and non-critical, can be looked at as features that need to be addressed in the system. With any features, there are tradeoffs between features and release date, so they need to be prioritized with the rest of the work (which may mean that non trivial bug fixes don't make it into a given release).

    In an agile environment, bugs can contribute to velocity for you and your team. There are two schools of thought as to whether or not bugs should be worth additional points or if they should be 0 points (and thus your velocity slows down, which may make sense since you didn't finish the feature correctly the first time). I think it really depends on the type of bug (was it a spec error or was it programmer logic error for example). But either way it will push your release date out and you need to make decisions as to their importance.

    So bottom line, treat them like you would anything else, another piece of the plan.

  4. Good Knowledge sharing information provide by you and it is helpful information.

    - Offshore Software Development