Skip to main content

Bugs Handling

We acknowledge that there is no software without bugs. Testing purpose is to find those bugs and fix them to minimize the risk of the software malfunctioning.

High-level process of bugs handling looks as follows:

  • Discovery - we use different methods for finding bugs.
  • Reporting - every found bug needs to be properly reported.
  • Triage - we screen bugs to assess their severity and priority.
  • Fix - we fix the bugs and cover them with tests.

Bugs handling process​

Below is a more detailed explanation for each step in the process.

Bugs discovery​

There are several ways we discover the bugs:

  • Testing - we run our tests that detect software deficiencies.
  • Tool-assisted reports - we use different tools to monitor our systems and we configure them to alert us whenever there is an anomaly.
  • Product Showcase meeting - we meet on a weekly basis to demo latest product changes and gather any deficiencies, which sometimes resolve to a bug.
  • User feedback - we collect users' feedback and investigate the reports to find a potential bugs.
  • Self-exploration - we test the software every time we work on developing it, thus we also find the bugs by ourselves.

Bugs reporting​

We use Jira to store the bugs and track their fixing process.

The process:

  1. Create a new bug in Jira in the Backlog
  2. Add a good title and a meaningful description (see bug report template)
  3. Assign the severity to the issue
  4. Attach a screenshot, if applicable
  5. If a bug has a critical severity, inform the team immediately using #-outages channel on Slack.

Bug report template​

A good bug report includes:

  • screenshot or short video clip if possible (it can be very helpful!)
  • meaningful title and detailed description
  • area of the product where the issue occurs
  • steps to reproduce
  • expected and actual results
  • environment info (versions of application, operating system, browser)

Bug labels​

Every bug needs to be assigned with a severity, product and environment labels based on the current knowledge (it may be adjusted later). If a bug is a regression (it was working before) - assign a regression label. Other labels are optional.

We use the following levels of `severity` of a bug:

  • low - affects low amount of users and doesn't break any feature; may wait for a fix
  • medium - affects some users and impacts some feature but doesn't break it completely; we need to look into it soon
  • high - affects big amount of users or breaks a feature or part of the user-facing software; we need to fix it as soon as possible
  • critical - makes the product unusable or exposes a security vulnerability; we need to fix it now

Product-related labels:

  • product:web_app - relates to Web Application
  • product:chrome_browser_ext - relates to Google Chrome extension
  • product:vscode_ext - related to VS Code extension

Environment-related labels (read more about the environments here):

  • env:local - happens in the local development environment
  • env:dev - relates to the development environment
  • env:qa - visible on the QA (Staging) environment
  • env:prod - appears on production environment

Bugs triage​

Every bug needs to be triaged, i.e. screened and prioritized. It needs to be done with the assistance of Product Manager(s), because they are the owners of the product's board. Preferably, the bugs should be triaged when they are being added, but we also triage them during the weekly QRB Meeting to not let them stay untouched for too long.

For bugs triaging we use Jira Bugs Triage Dashboard with issues filtered by bug type and ToTriage label.

  1. All new bugs land in the Backlog where they are being reviewed.
  2. Missing labels are added and the description is being updated, if needed.
  3. If the scope of the bug is unclear and we are not quite sure what needs to be done, we ask the stakeholders for more info - it may be the question to the:
    1. Designers whether the implementation is different than the design,
    2. QA Engineers whether the issue applies to some other places too or it is reproducible,
    3. Developers whether the issue relates to the defects in the code or in the infrastructure.
  4. If the scope of the bug is clear and we know what to do, we update the bug assigning:
    • Severity - how severe the bug is.
    • Priority - how fast the bug should be fixed.
    • Place in the backlog to improve visibility.

Note If the scope of the bug is still unclear, we let it stay in the bottom of the backlog state until it is decided.

If a bug is not relevant and/or will not be fixed, we delete the issue.

Bug fixing​

Every triaged bug needs to be fixed. Depending on the area it relates to, a different Engineer can be assigned to prepare the fix. Sometimes, the fix requires changes in the design, which needs to be aligned with the Designers.

Every fix needs to be covered by appropriate amount of unit tests. Consider adding higher-level tests that would prevent similar bugs to arise in the future.

Note If you find yourself stuck or you need help with the bugfix, don't hesitate and ask others. We work together, because we know that quality can be achieved only as a product of tight collaboration.

We document the stories behind the critical bugs and their handling process as blameless post-mortems, so that we can learn from our mistakes and be prepared for similar issues in the future.