4 tips to improve your team’s bug fixing process

Bug Fixing

With this article, which strays a bit from the more developer-focused articles we usually write, we aim to help managers of development projects better deal with bug fixing. 

You might consider bug fixing to be a developer issue, and depending on how you manage you might not consider it something you need to bother with. But bug fixing is not just a job on the developers’ task list; it’s a process that can involve everybody from users, testers and even you and the budget you have. 

No matter how talented and experienced your developers are, your software will inevitably run into bugs along the way. This can be because of faulty code, unexpected user behaviour or misunderstood expectations for the program. Bugs are a natural part of the development process, and they are only an issue if they aren’t discovered before release, or if the process of reporting and fixing bugs is so slow that it compromises the timeline and budget for the project.

The job therefore isn’t to avoid bugs, but to find out how to quickly deal with them. As project manager, it is your job to make sure the developer gets the best prerequisites to fix a reported bug. To do that, you need to make the process as smart and streamlined as possible. We have gathered the best advices, we could think of, to help you help your developer be an expert bug fixer.

Trust is the key

It might seem banal, but fact is that a lot of developers experience varying degrees of mistrust from the people who manage them. So even if this headline makes you go “Well duh!”, think of it as a reminder.

Whether you’re working with your own team of developers, freelancers or external contractors, it’s a key factor that you trust them to do what you’ve tasked them to. Especially when you’re managing somebody who’s working remote, which is becoming increasingly popular within software development these days.

For internal and external developers alike, we’ve found that two factors are central to create a foundation for a partnership built on trust:

  1. The personal touch
  2. Communication

The personal touch is basically treating your developers like people rather than a resource. Have conversations rather than just sending lists of orders; be positive and respectful in your communication; and be aware of their job satisfaction. Then you will have developers who take more responsibility and are honest with you.

Your communication is just as important, as this is where you make sure everything is understood and reported correctly. If you have a certain set of expectations but aren’t vocal about them, you will be disappointed. Weekly or bi-weekly meetings are a very good idea for making sure you share your expectations. Especially if the developers are working remote. Likewise, don’t let messages such as instructions or bug reports vary too much. Otherwise you will risk that the developers are unsure of what is expected from them and waste time asking questions. Worst case scenario is that they’ll misunderstand and fix something that shouldn’t be fixed.

Speaking of which…

Guidelines for bug reports

Given nothing to work from, it can be tempting for a user to just write “doesn’t work, please fix”. But this is understandably impossible for the developer to do without having to ask follow-up questions. It can be avoided by giving your users a strict template to follow, which should preferably include:

  1. A title with subject (e.g., “[LINKS] – Link broken between two pages”)
  2. Environment (device, OS, account, connection type, reproducibility etc.)
  3. Steps to reproduce
  4. Expected result vs. actual result
  5. Visual proof
  6. Priority (minor, medium, critical)

There are plenty of tools for bug reporting, such as Backlog and SpiraTeam, or maybe your company already has a program for bug reporting, but this could also just be an e-mail template.

Once you’ve set up a proper way of reporting bugs, it would be a good idea to

Prioritise test code

It might seem like extra work for small gains. But prioritising the code used for testing at the same level as production code will minimize the number of bugs in the live environment. And in the end, we can all agree that few to no bugs in the final product is worth the extra effort.

Instruct your developers to maintain the test code as carefully as project code. And always write unit tests for any change they make. Then the quality of the product will be way higher. Even if development initially slows down, the improved quality will more than make up for it.


Lastly, to manage your expectations with reality, a general rule of thumb for development projects, as with any other project, is to plan for worst case scenario.

Plan ahead

“How do you exit a casino with a small fortune?”
“You enter with a large fortune!”

Going over budget and over schedule is every project manager’s nightmare. If you plan with a pessimistic mindset, you hopefully won’t reach that point. It’s like the old saying: “It’s better to be pleasantly surprised than disappointed”.

We can’t give you a specific number of hours to allocate for bug fixing. That’s because it’s completely dependent on the project, the experience of the developers, and how well you manage the bug reporting process. A global survey found that over half of the 950 surveyed developers spends at least a quarter of their time fixing bugs. So if you’re brave enough to be that pessimistic, it’s a starting point for your contract calculations.


All of the above can be summarized into 4 headlines

  1. Create an environment of mutual trust and transparency
  2. Make thorough and easy to follow guidelines
  3. Prioritise your testing code
  4. Be pessimistic in your planning

No matter how experienced and skilled you are as a project manager, you might still find yourself way past a deadline on a project, asking yourself why. Consider our four pieces of advice and be honest with yourself: Could you have done something better? Was your communication structured and concise? Did you get too optimistic about how much time your developers needed to spend on bug fixing? Bugs may not even be the problem for your project, but considering your bug fixing process is always a healthy exercise.

May all your future software projects be low on bugs and high on performance!

bug fixing
Notify of
Inline Feedbacks
View all comments