Home / Blog / The Correct Way to Fix Software Bugs Fast

Blog

The Correct Way to Fix Software Bugs Fast

by Victor Purolnik
Blog
An image of a bug walking on a keyboard which depicts fixing bugs in software development

Software bugs, while cumbersome can, at most times, not be avoided at all. Why? Because software is built by humans and human beings make mistakes. In today’s article, we’ll take a look at the correct way to manage and fix software bugs as fast as possible.

Nobody likes bugs. But when they occur — get them fixed fast by following these guidelines to deliver all the information your developers truly need.

At Trustshoring, we always advise our clients to ensure that the necessary processes are in place to help them avoid software bugs upfront.

However, once they occur, how can you get them fixed as quickly as possible?

You don’t want your bug to be forgotten about, and you want it to be a top priority. To achieve that, make sure you use an issue tracker (no matter which one, actually). This will ensure your team knows its priorities and nothing will get lost.

Don’t write “The save button is broken”. In most cases, your team won’t know what that means. Even though it sounds dumb at first, not everything is as obvious as it seems to you. Bugs may be encountered only when entering specific data, taking a specific route to a page, or any other steps upfront. It may matter who you’re logged in as or what button you click. If you supply your team with that information upfront, you won’t have delays later.

Make sure your issue contains concrete steps to get to the problem (including direct URLs, user logins, button clicks, … ) in an ordered list, e.g.:

1. Go to the page with URL X
2. Log in as user Y
3. Click button Z

Let’s take another look at the commonly used bug report “The save button is broken”. This includes no information about what happens and what is supposed to happen instead.

Imagine you or somebody else going over the bugs in one month. Do you remember what exactly didn’t work? Probably not. Will you recognize when that problem happens again? Maybe. But you’ll have no trail of what was done, what was fixed, and why things went wrong.

Thus, right below the reproduction steps, write down the expected result. Given a user performs the steps above, this is what the result should be. Below, state the current result. Describe what currently happens instead of the expected result. That way, everybody knows exactly what’s wrong now, how to fix it and you can come back to it should it come up any time again in the future. Example:

Expected Result: The edit page opens in an overlay.
Current Result: The edit page opens in a new tab.

A short but good one: make a screenshot of the current result, and attach it to the issue. If you still think you need to open Paint to do that, here’s a list of free tools that will create screenshots for you very quickly.

If you can, please highlight the areas you’re talking about with red arrows or circles. Don’t ever write on the screenshots as the text can not be copied. Use the issue itself to describe the problem.

For even more clarity, state the version of the app that you’re using, the environment you were on (dev/stage/production), and your browser including its version number. Again, this will help everybody to find and fix the problem as soon as possible.

🎙️ Podcast

If you want to keep a healthy relationship with your team, not prioritizing every bug as “high priority” is key. If you assign everything a high priority, not only will your team stop taking your bugs seriously at some point, but the really important bugs will drown in the list of other “high priority” tasks and won’t get done fast enough.

So, to get the bad boys fixed quickly, choose accordingly:

  • Blocker: Users can not accomplish their main goal, and there’s no (obvious) workaround for them (e.g. not being able to find one’s friends on Facebook).
  • Critical: Users can only accomplish their main goal by using some sort of workaround (e.g. not being able to find a Facebook friend in one’s friends list, but being able to search for them).
  • Major: A significant amount of users feel uncomfortable accomplishing their main goal (e.g. the friends search on Facebook is suddenly terribly slow, but works).
  • Minor: Side goals can not be accomplished by users (e.g. the poke button disappeared on one’s Facebook profile).
  • Trivial: Cosmetic things (e.g. the poke button on Facebook uses the wrong font).

Recap: Get bugs fixed faster by

  1. using an issue tracker
  2. including reproduction steps
  3. naming the expected & current result
  4. making screenshots
  5. adding meta information
  6. and prioritizing correctly

Read more

Post link
blog
blog

How Does Trustshoring Work?

by Victor Purolnik
3 min read
Post link
blog
blog

How to Get Better Project Estimations from Web Developers?

by Victor Purolnik
18 min read
Post link
blog
blog

Remote Software Developers: Tips on Finding and Hiring

by Itotia Waiyaki
7 min read
Post link
blog
blog

The Essential Legal and Strategic Considerations for SaaS Founders

by Victor Purolnik
4 min read

Create a free plan for growth

Speak to Victor and walk out with a free assessment of your current development setup, and a roadmap to build an efficient, scalable development team and product.

“Victor has been great. Very responsive and understanding and really knows his stuff. He can go the extra mile by tapping into his prior experiences to help your company out. Really enjoyed working with him.”

image of Matt Molter Founder and President of Agency360
Matthew Molter

Founder of Agency360

Image of Victor Purolnik, the founder of Trustshoring

Victor Purolnik

Trustshoring Founder

Author, speaker, and podcast host with 10 years of experience building and managing remote product teams. Graduated in computer science and engineering management. Has helped over 300 startups and scaleups launch, raise, scale, and exit.

Subscribe to our Newsletter!