Bugs Management
Work In progress...
Last updated
Work In progress...
Last updated
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.
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.
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