🖌️
Product Process Documentation
  • Product Process Documentation
  • Definition of Done (DoD)
    • General checkpoints
      • Specific checkpoints by team
    • Important process: QA review & PO review
      • QA Review
      • PO Review
  • Work Items
    • Product Backlog Item (PBI)
    • Bug
      • Basic rules for creating a bug
      • How to report a Bug
    • Bugs Management
  • Code Standards
  • Different Test Levels
    • Unit Test
      • Frontend Unit Testing
        • What is a Unit Test?
        • How do I know if I am developing a good unit test?
        • AAA (Arrange, Act and Assert)
        • Overloaded test suits
        • Setup & Teardown
          • JEST Mocks
          • FakeTimers
        • Istanbul Annotations
        • C8 Annotations
        • JEST Runner (Debug unit tests with Jest)
    • Component Test
      • Frontend Component Testing
        • What is Component Testing?
        • Best practices
        • Bad practices
        • Setup
          • Sandbox
          • Mocks, Services and Providers
          • Test scenario
    • Integration Test
      • Frontend Integration Testing
        • What is a Integration Test?
        • AAA (Arrange, Act and Assert)
        • Best Practices
        • Bad practices
        • Setup & Teardown
        • How to create a scenario
          • Create the migrated app
          • Add to project
        • How to debug
        • Common problems
      • Testing Driven Development Guide and recommendations
    • Functional Test
    • Security Testing
      • Security Testing Tools
      • Frontend Security Testing
    • Performance testing
    • Best Practices
    • Test Documentation
  • Run test projects
    • General steps
    • Specific steps by team
  • DevOps
    • Pipelines
    • Builds
    • Specific information by team
    • Test plan
    • Service Hooks for Azure DevOps Notifications
      • Slack Notifications
      • Microsoft Teams Notifications
  • Dashboards
    • General
    • QA Dashboards
  • Release Process
    • General Steps
    • Specific steps by team
  • Migration Cells
    • Basics of testing process
  • Release process
  • References
Powered by GitBook
On this page
  • Bug grooming meetings
  • Bug management Matrix

Was this helpful?

  1. Work Items

Bugs Management

Work In progress...

PreviousHow to report a BugNextCode Standards

Last updated 3 years ago

Was this helpful?

The bug management is a systematic process that identifies, and fix bugs related to the project. The bug management consist of 6 steps related to the closure of a bug:

1) Discovery: the idea is to find as many bugs as possible before any end customer interacts with the product. After discovering a new bug, this is reported to the developer teams and after their acceptance the bug state will be set to accepted.

2) Categorization: we define a certain priority (critical: cause a failure on the product, high: cause inconvenience on the product, medium: minimal deviation from the requirements, low: very minimal deviation from the requirements) for a bug to help the developers to fix the bugs that are highly crucial priority.

3) Resolution: this step treats the fixing of a bug related to the product, this process starts with assign the bug to a developer, this schedule the bug to be fixed following its priority, the bug is fixed and finally report the resolution.

4) Verification: The testing team ensures that the faults have been repaired once the development team has rectified and reported them.

5) Closure: The status of a defect is changed to closed once it has been fixed and verified. If this is not the case, you must send a notice to development to have the fault checked again.

6) Reporting: In software testing, defect reporting is the process through which test managers produce and transmit a defect report to the management team for input on the defect management process and the status of problems.

Bug grooming meetings

These meetings have the goal to review the new bugs with stakeholders, team leads, product owners and developers, the objectives are check the definition of the bugs, if it is required, we can display a little demonstration of how to reproduce the bug, but the main objective is the set the priority and severity to categorize them by the bug matrix. Depending on the severity and priority assigned to the bug, it will be categorized with a certain color, which represents the impact of it inside the project, the categories will be explained in the next section. The average amount of bus to discuss in a bug grooming are from 5 to 7 bugs, but this numbers can be change from one team to another.

Bug management Matrix

This is a matrix made by taking the severity and priority of each bug to determinate which category it will have and how long is the time limit for this bug.

The image shown below is the demonstration of this explanation:

· Red category: These are the ship-stoppers bugs, this means that the bugs within the red category must be resolved before being able to launch a release related to a product, this bug must be assigned to a developer as soon as possible or on a period of 3-5 days.

· Orange category: The type of bugs in this category are usually mayor defects on certain feature but the user doesn’t always interact with it, this bug must be assigned to a developer as soon as possible on a period of 7-10 days.

· Yellow category: this bug represents an interaction that is rarely occurring, this bug must be assigned to a developer as soon as possible on a period of 13-15 days.

· Green category: these bugs are related to a minor feature request by stakeholders or bugs that doesn’t implies any risk or complexity, this bugs must be assigned to a developer as soon as possible on a period of 17-20 days.

If the bugs have not been assigned to a developer in the time estimated in the upper part (definition of categories of bugs), it will be the responsibility of the QA agents to raise the priority of these bugs, in order to raise their category, in case of that reaches priority 1 and is not been assigned to any developer with in the defined time, it will be categorized as a ship-stopper, this in order that bugs do not get stuck within the project's backlog