IS480 Team wiki: 2016T1 Stark Bug Metrics
|SCHEDULE METRICS||BUG METRICS|
What: Bug metrics are used to keep track of bugs found during development.
When: Bugs are recorded in the bug metrics document during testing at the end of each iteration.
How: 1 x num (Low Impact) + 5 x num (High Impact) + 10 x num (Critical Impact)
|Low Impact (1 point)||Typo error or small user interface alignment issues. Functionality of the application is still stable.|
|High Impact (5 points)||Though application is functional, some non-critical functions are not working|
|Critical Impact (10 points)||Application is not functional. Bugs must be fixed before proceeding.|
|BM <= 5||Application does not need immediate fixing, can be fixed during buffer days or coding tasks.|
|5 < BM < 10||Ultilize planned debugging time in the iteration to rectify the bug.|
|BM >= 10||Stop all current development and rectify the bug immediately.|
|Iteration||Bug Score||Bug Summary||Action Taken|
|The spike in bug count is due to the integration of dispute management system together with previous completed features.||Resolve bugs immediately. No major delay was caused.|
|The spike in bug count is because of the integration of many new features together for UT1.||Resolve bugs immediately. Iteration 8 was scheduled for post UT1 debugging. PM scheduled the Lead Backend developer to focus on debugging while the rest of the developers focus on development.|
|The first critical bug was system crashed when a dispute for review is filed. The second critical bug was images is not updated when listing image name is being edited.||Resolve bugs immediately. No major delay was caused. Critical bug did not occur again. Similar action was performed but bug did not replicate.|