Dealing with bugs can be a very dangerous experience… For a small company it’s possible to drown in the bloody things. Effectively getting a process in place can be difficult and time consuming. We currently have a few big projects on, so we know this first hand.
A few “givens” are necessary before any kind of bug process can be implemented.
We need to have:
- A “deployment” server (the live one)
- A “stage” server
- A system for tracking bugs
While developing a sprint there should be a “development” server – bugs are never reported on a development server as it’s always “bleeding edge” work in progress. This development can still be discussed in whatever project management software you may be using.
We use Mantis for tracking bugs, it’s not got the best interface around but it’s depth suits us well at the moment.
Our process isn’t some multi page document it’s just a simple list of rules that will make the client’s and our lives easier during the bug tracking phase.
All bugs and features must go into bug track
One mans bug is another mans butterfly… Put everything into the bug tracking system, ambiguous or not. Leaving things out just causes confusion later.
Any communication around a bug or feature must be in bug track
There’s no point getting a zillion emails about an already reported bug. As a project manager if you have to put it in; do it. Any correspondence can then be centralised around that bug.
All communication with developers must be through bug track
When a developer gets emails directly it messes with their minds. Nine out of ten developers rise to the challenge of the client, which is great, but the project manager needs to be involved, hence keeping everything in bug track.
When a bug has been received it will be assigned to a developer
In your bug tracking software you should be able to assign bugs to developers. This shows the client that you’ve acknowledged the problem. Once a problem is acknowledged and a line of communication is open a certain amount of stress is relieved on both sides.
If the bug is deemed to be a “feature” it will be assigned to the project manager for discussion
Developers are lovely. They will fit in this small feature even though it’s not really a bug. Anything ambiguous needs to be assigned to the project manager.
When we have looked at the bug we may have some questions
The developer will change the status to “feedback” – asking for what we need to know. The quicker it’s answered the sooner the bug will be resolved.
When we’ve fixed the bug we will push it to the “stage” server for approval
The staging area is the latest stable release before the deployment to the production server.
If the client is not satisfied that the bug is fixed – why?
We need clear information stating why and under what circumstances. This needs to be attached as a note against the bug in bug track.
When the client is happy that the bug is fixed – close it
A note in bug track needs to be attached to the bug. Only then will we “close” the bug.
We will not deploy to the live server individual bug fixes unless they are catastrophic
Deploying individual bug fixes is inefficient, so unless they are really really bad, they will be stored up into a daily or weekly release.
We will provide a list of fixed bugs deployed to the live server
It’s important to know what has been promoted from the staging server. A clear list of bugs and their issue numbers should be provided to the client either by email or in your project management software.
This is a work in progress, an evolutionary process if you like. It would be fantastic to compare this with other agencies so that we can collectively improve the way that we treat clients and out own efficiency.