This is a document that explains how Bug Management should work in the project. The contents of this document are:
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.
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.
- 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.
- 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.
| Status | Meaning |
|---|---|
TO DO | |
ACKNOWLEDGED | |
IN PROGRESS | |
CODE REVIEW | |
QUALITY CHECK | |
STAGING | |
STAGING VERIFIED | |
PRODUCTION | |
COMPLETED |
| Transition | Status change | Who does this | When 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.
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.
| Name | Definition | Who 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 |
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 |
|---|---|
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. |
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 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 |
|---|---|
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. |
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
Check out here on how to report a bug.
| Response / Acknowledgement | Resolution | |
|---|---|---|
30 minutes | 4 hours | |
8 hours | 24 hours (unless communicated otherwise) | |
2 working days | As per complexity of the bug and the capacity available. |
For smooth bug management and accurate resolution of bugs, all bugs should be verified within 2 working days.