Invos

05_bug_reporting_and_triage

3 min read

Bug Reporting and Triage

A systematic process for reporting and managing bugs is essential for maintaining high product quality.

How to Report a Bug

Anyone on the team can and should report bugs. When you find a bug, create a new issue in our project management tool (e.g., Jira, Asana), following the standards in our Task Management Guidelines. Include the following information:

1. Title

  • A clear, concise summary of the bug.
  • Good: “The ‘Save’ button is disabled after editing the user profile.”
  • Bad: “Profile broken.”

2. Description

  • Steps to Reproduce:
    • Provide a numbered, step-by-step guide on how to reliably reproduce the bug.
  • Expected Behavior:
    • What did you expect to happen?
  • Actual Behavior:
    • What actually happened?
  • Environment:
    • Where did you find the bug? (e.g., Local development, Staging, Production).
    • Browser and version (e.g., Chrome 108).
    • Operating System.
  • Screenshots or Video:
    • Visual evidence is extremely helpful. A screenshot with annotations or a short screen recording can save a lot of time.

3. Labels/Tags

  • Add the bug label.
  • Add any other relevant labels (e.g., frontend, api, ui).

Bug Triage Process

Bug triage is the process of reviewing new bug reports and prioritizing them. This is typically done by the Project Manager or a designated QA Lead.

  • Frequency: Triage should happen at least once a day.
  • Goal: To ensure every new bug is reviewed, prioritized, and assigned.

Triage Steps:

  1. Review the Bug Report:

    • Is the report clear? Is there enough information to reproduce the bug?
    • If not, ask the reporter for more details.

  2. Reproduce the Bug:

    • Follow the steps to confirm that the bug is real.
    • If you cannot reproduce it, the bug may be closed or sent back for more information.

  3. Assign a Priority:

    • Not all bugs are created equal. We use the following priority levels:

      • P1 (Highest): A critical, show-stopping bug. For example, the application is crashing, users can’t log in, or data is being corrupted. These must be fixed immediately.
      • P2 (High): A major feature is not working correctly, or there is a significant impact on the user experience. No acceptable workaround exists. Fix in the current or next sprint.
      • P3 (Medium): A minor feature is not working, or there is a UI issue that affects the user experience but doesn’t block them. A workaround may exist. Schedule for a future sprint.
      • P4 (Low): A cosmetic issue (like a typo or a misaligned element) or a bug with very low impact. Fix when time is available.

  4. Assign the Bug:

    • Assign the bug to a developer or put it in the sprint backlog to be picked up.

The Bug Lifecycle

A bug goes through several statuses in our task management tool:

  1. To Do: The bug has been triaged and is ready to be worked on.
  2. In Progress: A developer is actively working on a fix.
  3. In Review: The fix has been implemented and is in a Pull Request, waiting for code review and QA validation.
  4. Done: The fix has been merged, deployed, and verified.
  5. Won’t Fix: In some cases, we may decide not to fix a bug if it’s very low priority and the cost of fixing it is too high. This decision should be clearly communicated in the bug report.

Graph View

Backlinks