🐞

Bug Management

Created
Mar 4, 2022 1:44 PM
Department
Project Management
Category
Processes
Technology
Tags
Date
URL

This is a document that explains how Bug Management should work in the project. The contents of this document are:

Definition of a bug

bug is an error, flaw, failure or fault in a program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

Types of bugs

Bugs are classified on the basis of severity. While reporting a bug the reporter will be required to select the appropriate severity of the bug being reported. Each type of bug is explained below:

Severity 1 – Critical

Complete failure of the system. The user is unable load or access the system. Eg. One of the platforms is down.

Severity 2 – High

The primary user flow is affected which prevents the user from performing actions on the system that are critical to business operations. Eg. A user on YOP is unable to apply for an opportunity.

Severity 3 – Moderate

An essential part of the system which offers assistance to the user but is not part of the primary user flow is not working. Eg. Analytics in EXPA is not working.

Severity 4 – Low

A functionality which does not have a high degree of impact on the primary actions a user can perform on the system is not working. Eg. The gender filter in the CRM is not working.

Severity 5 – Cosmetic

There is a problem with the look and feel of a part of the system which has no consequence on the functionality of that part of the system. Eg. Alignment, Color, Text issues.

Bug Impact
  • Single user: Only a single user is affected from the bug.
  • Multiple users: Number of users affected are more than 1.
  • All users: All users are affected.
  • Not sure: Not sure if more users are affected.
Priority guideline
  • The following serves as a guideline to choose the priority of a bug.
  • However, if there is a Severity 5 or any other severity issue which needs to be done urgently then the priority field can be used to denote its urgency.
Priority guideline matrixSeverity 1 – CriticalSeverity 2 – HighSeverity 3 – ModerateSeverity 4 – LowSeverity 5 – Cosmetic
All users
High
Medium
Low
Lowest
Multiple users
High
Medium
Low
Lowest
Not sure
High
Medium
Low
Lowest
Single user
Low
Low
Lowest
Lowest
Different statuses and their meaning
image
TransitionStatus changeWho does thisWhen do they do this?
TO DO → ACKNOWLEDGED
Development team leader
The team leader has:- Read the bug ticket.- Understood the bug being reported.- Confirms there is sufficient information for the team to proceed with investigation.
ACKNOWLEDGED → IN PROGRESS
Assigned developer
The developer has initiated investigation on the bug.
IN PROGRESS → CODE REVIEW
Assigned developer
The developer has:- Fixed the reported issue.- Requested their team leader to review the code before the code can be put on the staging environment.
CODE REVIEW → QUALITY CHECK
Lead developer
The team leader has:- Reviewed the code and approved it.- Deployed the code to the staging environment.
CODE REVIEW → IN PROGRESS
Lead developer
The team leader:- Is not satisfied with the code submitted for review.- Has given specific feedback on what needs to be changed.
QUALITY CHECK → STAGING
Assigned developer
The developer has:- Verified that the fix works as expected on the staging environment.
STAGING → STAGING VERIFIED
Product owner / Development team leader (for technical bugs)
The product owner has:- Verified that the fix works as expected on the staging environment.
STAGING → IN PROGRESS
Product owner / Development team leader (for technical bugs)
The product owner has:- Found a mis-match between the current output and the expected output as per the description of the ticket.
STAGING VERIFIED → BETA
Development team leader
The team leader has:- Deployed the code to the beta environment.
BETA → BETA VERIFIEDThis transition will only occur in a situation where the development team leader feels that the bug needs to be verified on beta before moving it to production.
AIESEC product manager
The AIESEC product manager has:- Verified that the fix works as expected on the beta environment.
BETA → PRODUCTION
Development team leader
The development team leader has:- Deployed the code to the production environment.
PRODUCTION → COMPLETED
AIESEC product manager
The AIESEC product manager has:- Verified that the fix works as expected on the production environment.

The overall ownership of the ticket is on the developer assigned. They are responsible for ensuring the ticket moves to completed at the earliest.

The “Who does this“ field mentions the person who transitions the ticket in an ideal workflow. However, in the case where the current assignee of a ticket needs more information from someone or is blocked because of a dependency then the assignee can change to another person.

Dependency management

Ideally all dependencies should be taken care of in the sprint planning meeting. However if there are dependencies realized after the sprint planning meeting please refer this link to learn how to manage it.

Ticket fields specific to bugs
NameDefinitionWho fills?When to fill?
The degree of impact the bug has on the system.
Reporter
Creation of the ticket
The number of users affected from the bug.
Reporter
Creation of the ticket
The order in which a bug should be worked on.
Reporter
Creation of the ticket
What led to the bug on the production environment.
Developer assigned
IN PROGRESS → CODE REVIEW
A brief description of the core reason behind the issue and what actions were taken that the bug does not recur.
Developer assigned
IN PROGRESS → CODE REVIEW
How did the bug get exposed?
Reporter
Creation of the ticket
Bug sources

A bug source is the reason which led the bug to make it to the production environment. Below all the sources/options are listed with their definition.

SourceDefinition
The issue has already been resolved and the ticket being referred to doesn’t need to be worked on. This can happen in a case where between the time in which the user was affected by the bug and the time that a developer investigated the issue, a fix was deployed to the production system to fix the bug.
Syntax errors that should not have passed tests. Non-adherence to business rules clearly defined in the issue. Feature does not work in the most general work flow as well.
After investigation we found out that the reported issue does not classify as a bug as per the definition of a bug. For example, a user could not perform an action because they didn’t have the permission to perform the action. In this case if the permissions are set-up correctly as per the permissions framework then this will not qualify as a bug.
The issue was because of incompatibility with features delivered by other suppliers contracted previously or in case the feature has not seen any active development, usage in the last 6 months.
The issue was because of additional load on the database/servers.
The issue was because of compatibility with a third party service.
After multiple attempts the assigned developer was unable to reproduce the bug and hence is unable to investigate further.
The issue occurred due to a scenario which could not have been predicted before the user actually experienced the bug.
Bug report

A bug report is a brief description of the core reason behind the issue and what actions were taken to ensure that the bug does not recur. A bug report should contain the following elements:

Bug source description

  • An elaboration on the bug source. For example if the bug source was “System performance issue“. then the explanation should involve what caused the number of requests to increase which increased the load on the database.

How was non-recurrence handled?

  • Explanation on what changes were made which not only fix the bug for the moment but also ensure that the bug will not recur in the near future.
Reporting source

Reporting source is the identification of the source from where the bug got exposed. It helps in understanding which bugs are being reported by users vs which are being caught by proactive measures. The table below explains each of the reporting sources and their definition.

Reporting sourceDefinition
The AI platforms team found this issue while manually testing the platform.
The automated tests exposed the bug.
One of the error tracking platforms like Sentry or Rollbar exposed the bug.
The bug was exposed through manual testing done by the Commutatus team.
The bug was reported by a user of the platform.
Description of the ticket

The description of every bug ticket should have the following elements:

Overview

  • General explanation of the bug.

Expected behavior

  • How should the feature / functionality being reported ideally behave.

Actual behavior

  • How the feature / functionality being reported currently behaves.

Instances of the bug

In order of priority any of the following:

  • Screen recording of the bug occurrence preferably with the console
  • Screenshot of the bug occurrence preferably with the console

Specific details

  • Details of the affected user(s) like email id, name, user id etc.
  • Details of any other components affected like opportunity id, opportunity name etc
  • Any other details which may be relevant to the bug

How to replicate

If there is a screen recording of the entire flow then this section can be left empty. In case there is no screen recording available then the reporter is required to fill this in the format below:

  • Go to the affected page
  • Perform the affected action
  • Check the wrong outcome

Check out an example of a well reported bug below

image
How to report a bug?

Check out here on how to report a bug.

Response and resolution timelines
Response / AcknowledgementResolution
30 minutes
4 hours
8 hours
24 hours (unless communicated otherwise)
2 working days
As per complexity of the bug and the capacity available.
Verification timelines

For smooth bug management and accurate resolution of bugs, all bugs should be verified within 2 working days.