Link Search Menu Expand Document

Bug Management

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

Definition of a bug

A 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 matrix Severity 1 – Critical Severity 2 – High Severity 3 – Moderate Severity 4 – Low Severity 5 – Cosmetic
All users Highest High Medium Low Lowest
Multiple users Highest High Medium Low Lowest
Not sure Highest High Medium Low Lowest
Single user Medium Low Low Lowest Lowest
Different statuses and their meaning

different-status-meaning

Status Meaning
TO DO 1. Initial status of any ticket after creation.
2. The ticket has been created with all the mandatory fields filled out.
ACKNOWLEDGED The developer/product owner has seen the bug ticket and is aware of the severity, impact and priority it holds but has not started any investigation on it.
IN PROGRESS The assigned developer is either investigating or fixing the issue.
CODE REVIEW The developer has completed work on the ticket and has requested for his code to be reviewed by a peer.
QUALITY CHECK 1. The developer’s code has been approved and the fix has been deployed to the staging environment.
2. It is being reviewed by the assigned developer on the staging requirement.
STAGING 1. The developer has verified that the fix works as expected on the staging environment.
2. The product owner is in the process of verifying whether the fix works as expected or not on the staging environment.
STAGING VERIFIED 1. The product owner has verified that the fix works as expected on the staging environment.
2. The product owner has given the assigned developer the permission to deploy the code to the production environment.
PRODUCTION 1. The fix has been deployed to the production environment.
2. The AIESEC platform manager is in the process of verifying the fix on production.
COMPLETED The fix has been verified on production and the ticket has been resolved and closed.
Transition Status change Who does this When do they do this?
Acknowledge the bug TO DOACKNOWLEDGED 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.
Start work ACKNOWLEDGEDIN PROGRESS Assigned developer The developer has initiated investigation on the bug.
Submit for code review IN PROGRESSCODE 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.
Submit for quality check CODE REVIEWQUALITY CHECK Lead developer The team leader has:
- Reviewed the code and approved it.
- Deployed the code to the staging environment.
Changes required CODE REVIEWIN 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.
Deploy to staging QUALITY CHECKSTAGING Assigned developer The developer has:
- Verified that the fix works as expected on the staging environment.
Verify on Staging STAGINGSTAGING VERIFIED Product owner / Development team leader (for technical bugs) The product owner has:
- Verified that the fix works as expected on the staging environment.
Changes requested STAGINGIN 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.
Deploy to beta STAGING VERIFIEDBETA Development team leader The team leader has:
- Deployed the code to the beta environment.
Verify on beta BETABETA VERIFIED

This 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.
Deploy to production (directly from beta) BETAPRODUCTION Development team leader The development team leader has:
- Deployed the code to the production environment.
Verify on production PRODUCTIONCOMPLETED 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
Name Definition Who fills? When to fill?
Severity The degree of impact the bug has on the system. Reporter Creation of the ticket
Impact The number of users affected from the bug. Reporter Creation of the ticket
Priority The order in which a bug should be worked on. Reporter Creation of the ticket
Bug source What led to the bug on the production environment. Developer assigned IN PROGRESSCODE REVIEW
Bug report A brief description of the core reason behind the issue and what actions were taken that the bug does not recur. Developer assigned IN PROGRESSCODE REVIEW
Reporting source 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.

Source Definition
Has already been resolved 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.
Human error 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.
It is not a bug 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.
Legacy code 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.
System performance issues The issue was because of additional load on the database/servers.
Third party issues The issue was because of compatibility with a third party service.
Unable to reproduce After multiple attempts the assigned developer was unable to reproduce the bug and hence is unable to investigate further.
Was an unpredictable scenario 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 source Definition
AI Platforms team The AI platforms team found this issue while manually testing the platform.
Automated tests The automated tests exposed the bug.
Error tracking platform One of the error tracking platforms like Sentry or Rollbar exposed the bug.
Manual testing The bug was exposed through manual testing done by the Commutatus team.
User 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

bug-description-example

How to report a bug?

Check out here on how to report a bug.

Response and resolution timelines
  Response / Acknowledgement Resolution
Severity 1 30 minutes 4 hours
Severity 2 8 hours 24 hours (unless communicated otherwise)
Severity 3, 4, & 5 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.