Tips for resolving a bug

In a perfect world there would be little need for debugging. Unit tests would be in place for all existing code and whenever a spot was missed a test would simply be added to cover the whole. In the real world or at least the world that I work in there is much legacy code. There also other things that affect system functionality such as system complexity - our app is close to two million lines of code, familiarity with the system, developer experience.

These things require the developers to follow a structure format when resolving new bugs. Here are some tips that I came up with and passed down to my team.

The steps don’t have to be done in the exact order but they should be done prior to sending the ticket up for code review.

1. Duplicate the error
If you can’t duplicate the error don’t move beyond this step. At this point do whatever you have to do see the error for yourself in your box. Do not even think about fixing code that will work in theory. I have been bitten by this many times.
2. Study the problem and the functional area
Make sure you understand at a high level the problem that you are solving and peripheral areas. Do you really understand what the codes BC1 and BC0 mean and why the code can’t go from BC1 to CC2 (hypothetical codes)? Understanding what you are doing will help you solve the problem much easier.
3. Debug and find the problem
Run the problem and find out where it takes the wrong turn. There is an opportunity here to discover the intent of the code. Code is always good at telling you what it’s doing but not why. Can it be written better to be more understandable? If it can keep that in mind when you refactor it and also when your write new code.
4. List your assumptions and unknowns and discuss them with the business analyst or customer if you have one.
You are allowed to assume anything and everything you want about a system except that your assumptions are correct. Have your assumptions verified by someone who knows more about that area than you do. This could be a BA or a more senior developer.
5. If you can’t reproduce the problem, have the person that created the ticket reproduce the problem in their box. Many times this will reveal incorrect assumptions about how you thought the bug was supposed to be re-produced. At other times it will provide an opportunity to explore the difference between your environment and the environment where the bug was discovered.
6. Explain the problem and how you plan to solve it to someone else.
Normally we are all under pressure to get things done quickly. For that reason everyone is always busy with something. However what’s good for the team is good for the individual. Slow down and present the problem to another developer and have them see it. Explain it to a BA. Many times the BAs will understand enough or pick up on enough of your programming lingo to provide clues about the right solution.
7. Solve the problem in code.
Once you solve the problem test it out in the other scenarios that apply not just the scenario that the bug was found.


Three key things that we must keep in mind throughout the process are:

1. Document your research - in our company we should do this in our Bug Tracking system; Trac
2. Open communications with the entire team (BAs, Testers, Developers)
3. Slow down - to provide the correct solution. The right solution seems slower at first but it’s actually faster when you consider re-work.

Comments

Nolan Egly said…
6.5) Write a failing unit test that proves the defect exists
8) Ensure unit test now passes, proving the defect has been fixed.
9) Ask yourself, "Where else might this error have occurred?" Try to use an automated method to detect other potential occurrences.
January 14, 2010 at 6:33 AM
Post a Comment

Popular posts from this blog

Putting Files on the Rackspace File Cloud

Recently, I’ve been playing around with Asp.Net MVC and I (along with some friends) am creating an Asp.Net MVC application that can access files from our website. This means that files must display on the site as well as provide a way to download/upload them. I won’t give away all the details of the project but I will say this: Sharing photos is one of the driving forces for our project.  The files are only image type files( jpg, etc) The files must be uploaded by the users and stored somewhere within our system.  We don’t necessarily know at this time how much storage space we need but we think that we will need a little at first but possibly a lot more down the road. This means that the storage of these files must be scalable. The uploading of files must be controlled by our system.  Right off the bat we started our application and were uploading files to the web server with no problem.  We only did it this way to kind of prove our system model. We were just basically writing
Read more

Setting Up XnaMobileUnit to run unit tests in Windows Phone 7 XNA Games

Image
Introducing XnaMobileUnit I decided to roll my own unit test framework for Windows Phone 7 XNA games.   I have a couple of reasons why I decided to roll my own.  Among them was the fact that you cannot reference regular .Net assemblies from Windows Mobile Framework.  That means that referencing NUnit was out of the question.  Also using some of the other libraries that can be used for Silverlight Applications didn't quite feel right for me. The framework that I have created, XnaMobileUnit, is very simple to use and provides all the necessary functionality to run unit tests.  I am still working on the framework to provide a few more capabilities and features, but for the most part it is ready to use out of the box.  XnaMobileUnit is open source licensed under the Apache 2.0 License and can be downloaded from http://code.google.com/p/xna-mobile-unit/ .  I recommend downloading the latest source and compiling it then referencing the new DLL. Otherwise you can simply download the l
Read more

Reasons to Stay Away from CSLA

We've been using CSLA - Component-based Scalable Logical Architecture in a product for approximately one year and while it solves quite a few problems it violates some major good practices. No Clear Separation of Layers While at the time that we chose CSLA we knew very little about domain driven design, it is no excuse for the framework to possess the data access layer within the business object. This makes it extremely difficult to separate the concerns. As a result, it is difficult to mock the data-access layer creating many problems when attempting to perform unit tests. This also puts the additional responsibility of data access on the business object class, violating the Single Responsibility Principle( SRP ). Data access layer should be totally separated from the business object period. Having the data access within the within the BO class is not the only additional responsibility placed on the class but is the most significant one I can think of. No Context Validation
Read more