What is a Bug Fix?

Bug fix – elimination of software errors

The elimination of software errors is called bug fixing. A bug fix is the result of a bug removal, bugfixing is the activity of fixing bugs. What sounds relatively easy in theory is often a challenge in the practice of software development.

Before a bug fix can be implemented, a bug must be identified and located. Bug identification is often done by users, while localisation is usually done by support and/or development teams. What are the effects and severity of a bug? When does the bug occur, in which use cases or scenarios, in what frequency and with what consequences?

The prioritisation of bug fixes

Ideally, the answers to these questions are recorded in writing for each identified defect – another common word for bug – so that they can be used to prioritise bug fixing:

• Low: The bug is merely documented and only brought up for discussion again when its frequency or severity increases.
• Medium: The elimination of the error is discussed in the course of the next planning round – e.g. in sprint planning, iteration or release planning – and, if necessary, scheduled.
• High: Error correction is included directly in the current iteration or sprint.
• Very high: The error is so elementary that the elimination cannot wait for the end of the current development interval. A direct, immediate solution is necessary. The provision of troubleshooting can take place as a hotfix.

In the course of refactoring, so-called code smells are often discovered, i.e. constructs in the code that work but could be better structured. The removal of such code-smells is not considered bugfixing. However, if actual errors in the code are discovered during refactoring and then corrected, this is a bug fix.

How long does it take a developer to fix a bug?

There is no universal answer to this question. Often, however, eliminating the error is not the biggest challenge; the biggest challenge is identifying the cause of the error. A few questions can help here:

• Which user discovered the error and what action triggered it?
• What was the expected behaviour, what actually happened and what error message appeared?
• In which environment (e.g. operating system, end device) did the error occur?
• Are there any screenshots showing the error?
• And are there any tickets from the past for similar errors?

A simple rule is: the more effort developers have to put into answering these questions, the longer it takes for bug fixing to begin. Or the other way round: the more of this information is available, the faster and easier developers can fix the bug.

The documentation of bug fixes

It is common practice that bug fixes are documented not only internally, but also for users. This can happen in a separate bug fix log or in a change log. Most documentation also contains information on how to put the bug fixes provided as patches, hotfixes, updates or upgrades into operation.

Notes:

You are welcome to share or link to the content on this page.

Here you can find additional information from our blog: