Managing your bugs

Daishik
4 Jun 2021
0

In a previous post I wrote about how and why bugs may appear in your - or indeed any software.

Suppose you're aware of a bug or several bugs in your business software. Actually, even if you don't have any bugs, but just want to be prepared, what can you do about it?

Who you gonna call?

Get in touch with a software developer and discuss the issue. Together you'll be able to work out possible root causes and potential fixes, or if not you'll get some guidance as to further steps, including finding the right expertise for the problem.

Once you have someone who understands the issue, or is capable of investigating it further you need to remain engaged in the resolution.

Prioritisation

As some bugs can take a long time to fix, it is important that you have a clear idea in mind as to which bugs are your highest priority when you have multiple issues.

Software developers do have ideas about ranking the criticality of bugs on a technical level, but you need to provide guidance on your priorities from a business perspective. Work with your developers to prioritise and triage your bugs objectively. Remember not every bug needs to be fixed! It is certainly feasible that some bugs are so low impact that you can simply live with them.

Think about what will help your users most, and get them working effectively sooner. Does that icon really need to be moved right now? Or is it more important to deal with that page which throws a server error when a customer postcode is updated?

I've worked in some organisations where every bug is 'high priority'. This doesn't help you or the developers to make the most efficient use of time to get your business back on its feet.

After sorting your bugs by priority, there are 4 stages to a bug fix and getting to the end depends on each stage being successfully completed:

1. Identification

This is usually down to you and your users or staff in the first instance. After all, you know when something isn't working properly. It may be obvious: a screen which doesn't load, an error message, or incorrect data. Or it could be a bit more subtle - a missing file or piece of data or a process that takes too long to run.

2. Reproduction

This is about the information you can gather about the problem. If a problem is to be reliably understood and then verifiably fixed, it needs to be predictable. So you have to figure out how to make the problem appear on demand.

If you think you hear your car making an odd noise when you're turning left, you'll want to confirm this by running your car and doing multiple left turns! Working out the precise sequence steps that lead to the problem is a critical part of working out what is happening 'inside' the software and is vital to finding a solution.

For example: "If I do X, Y and Z (in that order) the operation will work. But if I do Z first and then X, then Y the screen will show an error message."

Conversations with a software developer may help you find strategies to gather information about the error, including error monitoring and encouraging your staff and users to log what they were doing every time they encounter this bug.

3. Resolution

Now the work passes over to the software developer, although your user information may still be required about reproducibility, especially for complex bugs. Armed with this information, developers will work in the code to figure out what is happening and why. They can then devise a patch or fix. After some basic testing, the bug will be marked as "resolved" or "fixed".

4. Verification

The patched application will be deployed into an environment where users can verify the fixes using "real world" scenarios. Users should be able to work through all their reproducibility scenarios without encountering the same issues. You should also check for 'regressions'. A regression occurs where the patch fixes the bug in question, but incidentally breaks something else - i.e. the patch gives rise to another bug!

It must be stressed however, that some bugs are notoriously difficult to fix, and you may have to perform these steps multiple times before you can finally 'close' the bug.

Be prepared

Whilst we're on the topic of bug management, how can we minimise the impact of bugs on business?

If you are just starting out with a newly developed software application, use the pilot phases to exercise every possible scenario of usage. Make sure the developers have a plan for quick fix and deployment of issues when they arise, but be prepared for longer fix times. This means that you shouldn't completely rely on the software and should continue your old processes in parallel for a while.

Backup, backup, backup

Well, you should always backup your business critical data.

When it comes to new applications that work directly with important business data, it is even more critical to ensure you make and keep regular backups. Having backups means you can restore your data to a point before a significant problem occurs. It also enables you or your software developer to trace problems by comparing 'before' and 'after' snapshots of the data.

Did I mention you should backup your data?

Be prepared

Make sure you have an alternative or offline system by which your business can continue to operate if your main system hits a critical bug.

This could mean going back to pen and paper. Or perhaps a simpler, albeit more manual alternative - if your database or application can't be used, do you have spreadsheet templates that can be used to temporarily capture data? It is a good idea to practice your disaster recovery scenarios at least twice a year, and to document the process.