In 1947, programmer Grace Hopper noted a malfunction of the Mark II computer that was caused by a moth found in the electromechanical components. Hopper and members of her team began to use the term 'bug' to describe computer malfunctions. In the 1940s, there were only a handful of such devices around the world and computing and programming were in their infancy. The term "bug" was therefore popularised to describe any unexpected computer behaviour and it became part of programming jargon.
Types of Bugs
Experiencing different types of errors in programming is a huge part of the development process. The best developers become comfortable navigating the bugs they create and quickly fixing them. Ther are different origins of these bugs:
- The easiest to fix are programmers' shortcomings resulting from the lack of knowledge or experience of a particular programmer, their haste, or lack of attention.
- Unforeseen situations, such as unexpected hardware operation, unanticipated sequence of user events (e.g., selecting options on the screen in a different order than expected), or a combination of both, are usually more difficult to fix.
- Errors resulting from faulty, imprecise, or contradictory requirements are the most difficult to fix. They require re-analysis of the requirements, correcting them, and designing, implementing, and testing them again. These are the most costly bugs.
In the first two cases, before the developer can successfully fix the bug, they must first identify the cause and repeat the sequence of events leading to the bug. It is therefore important to document the bug or defect report thoroughly.
Good practices for managing bugs
If you’re going to write software, you’ll undoubtedly run into a few bugs along the way. Here are some quick tips on how to efficiently manage and track those bugs.
Track bugs on your backlog
As a project manager, I can choose with my team how we want to manage bugs. Some teams prefer to track bugs along with requirements. Other teams decide to track bugs as tasks performed in support of a requirement.
Appropriate bug description
Appropriately described bugs let us capture both the initial issue and ongoing discoveries made when triaging, investigating, fixing, and closing the bug. That is why we have a general template for this kind of work item. We distinguish main points, let’s run through them:
- Title
The title most often refers to the environment where we find the defect and the role of a tester user. Then we describe the type of bug. See the example below:
[environment] - [role] - description of the bug/tape
[ dev | uat | prod] – [admin | user | manager] – can’t log in to app
- Steps to Reproduce
Here we enter a comprehensible description which lets us capture enough information to understand the full impact of the problem. This includes actions taken to find or reproduce the bug and its expected behavior.
First, we describe steps to reproduce the bug (often supporting it with screenshots or recordings). Let’s see the example:
Current situation:
When trying to log into the application with an administrator account, the log in button does not perform any action.
Steps to reproduce:
1. Go to the login page
2. Enter correct login
3. Enter correct password
4. Click the Login button
Then, we describe the criteria that the team should use to verify whether the code defect is fixed. That allows us to effectively evaluate whether an item has been satisfactorily completed.
Expected Behavior:
Once the correct details have been entered, the administrator should be able to log into the application.
- System Info
Information about the software and system configuration such us:
Affected Branch:
Affected Build: Each deployment bumps the build version from 0.1.0. to 0.1.1, 0.1.2 etc.
So, when reporting a bug, the build number should be added.
Operating system: Windows XP, Windows 7, Windows 8, Windows 10, Android, IOS, MacOS
Browser: Google Chrome, Mozilla Firefox, Opera Web Browser, Safari Web Browser, Internet Explorer
Set the priority
Priority is a subjective rating, and it relates to business. It shows the order in which code defects should be fixed. We specify the following values:
- 1 – Product cannot ship without it, do it as soon as possible.
- 2 – Product cannot ship without it, does not need to be done immediately.
- 3 – Work item is optional based on resources, time, and risk.
- 4 – Work item is not required.
Set the severity
Severity is a subjective rating of the impact of a bug on the project. We specify the following values:
- 1 – Critical. Must fix. A defect that causes extensive data corruption or impacts one or more system components. No acceptable alternative methods to achieve the required results exist.
- 2 – High. Consider fix. A defect that causes extensive data corruption or impacts one or more system components. However, an acceptable alternative method exists.
- 3 – Medium. A defect that causes the system to produce incorrect, incomplete, or inconsistent results.
- 4 – Low. A minor or cosmetic defect. Acceptable workarounds exist to achieve the required results.
The Quality Acceptance team member who knows the customer requirements can easily determine the severity.
Use templates as often as you can
Bug item templates are useful. Templates support such objectives as:
- Creating bugs for specific product areas
- Providing guidance to fill out the work item
- Defining standards
- Creating work items with specific tags
As we can quickly create work items that have prepopulated values, we save time.
Use the Discussion section
We use the discussion section in the Azure DevOps management tool to add and review comments made about the work being performed. Naturally, we discuss the tasks in detail, as work progresses. Appropriate comments under the tasks clarify doubts and facilitate the work of testers.
Automate reassignment based on state change
Azure DevOps Boards let us configure a rule which reassigns the bug to the person who created it as soon as the state of work item changes to Resolved. This rule is optional, but highly recommended - it facilitates the management and speeds up the willingness to test.
Never let from sight
Defects are tricky. Sometimes, bug fixes involve more than a single section of code. That requires regression testing. So, we record any symptoms and assess the risk of bugs. Some analyses related to Active bugs by priority, In Progress bugs, Bugs to fix for a target release or especially Recent bugs, are highly recommended.
Bugs Are Inevitable
Software bugs have a variety of origins, ranging from programmer shortcomings, through unforeseen situations, to errors arising from requirements. It should be emphasised that it is normal for them to be there.
However, the number of errors in software is correlated with the widely understood quality of software. As project managers, we support this quality through good project management practices.
