HeaderSIS.jpg

IS480 Team wiki: 2015T1 4Sight Bug Metrics

From IS480
Jump to navigation Jump to search
4Sight team logo.png
4Sight Home.png HOME   4Sight Team.png ABOUT US   4Sight Project overview.png PROJECT OVERVIEW   4Sight Project management.png PROJECT MANAGEMENT   4Sight Documentation.png DOCUMENTATION  
Project Schedule Software Development Methodologies Schedule Metrics Task Metrics Bug Metrics Risk Management Change Management

Bug Severity Metric

Bug severity metric.png

Bug Priority Metric

Bug priority metric.png

Bug Metric

Bug score metric.png

Summary of bugs by severity

4Sight BugsBySeverity.JPG

Summary of bugs by priority

4Sight BugsByPriority.JPG

Bug Metric Score & Description

Click Here to access our detailed bug records


4Sight BugMetricScore.JPG
Sprint Bug Score Summary of bugs Action Taken
0 0 No bug found No action required
1 0 No bug found No action required
2 29 2 low bugs, 4 medium bugs and 1 high severity bug found.

The 2 lows bugs were related the displaying of calendar.

The 4 medium bugs were related to the CRUD of appointments.

The high bug was due to the lost of appointments when user switched between different views.
Used the planned debugging time in the sprint. Team was able to fix all the bugs within the scheduled time.
3 19 4 low bugs, 1 medium bug and 1 high severity bug found.

The low bugs found were mainly due to minor user interface and interaction functions.

The medium bug found was due to incorrect referencing of index in the database which resulted in duplicated record made each time an appointment is created.

The high severity bug was because the calendar appointments are being pushed into the calendar before the calendar renders fully, resulting in no appointment record displayed on calendar.
Used the planned debugging time in the sprint. Team was able to fix all the bugs within the scheduled time.
4 14 1 low bug and 3 medium severity bugs found.

The low bug was caused by the minor logic error in the calculation of conversion rate.

The 3 medium bugs were due to:
* invoking 2 methods on click as the application cannot distinguish between single and double clicks.
* API call included null appointment records.
* The chart is not displaying all existing marketing channels but is showing only channels that registered patients were admitted with
Used the planned debugging time in the sprint. Team was able to fix all the bugs within the scheduled time.
5 60 3 low bugs, 7 medium bugs and 4 high severity bugs found.

The low bugs are mainly minor interaction issues.

The 7 medium bugs were due to:
* Appointments on calendar were unordered and appointments on heatmap were scattered when deployed to heroku
* y2 axis of chart disappeared
* Appointment with waiting list was deleted correctly
* Heroku does not account for lowercase when doing a search
* Notification not updated correctly
* The heat map color coding was not accurate when activated. For example, 5 patients should be displayed in red but instead displayed as green.

One of the high bugs was because the Heatmap was not activated when creating an appointment. The other 3 high bugs were caused by the temporary waiting list queue which affected the CRUD of appointments
Team stopped all current development then and resolved the bugs immediately. All bugs were fixed within the scheduled time.
6 0 No bug found No action required.
7 21 1 low bug and 5 medium severity bugs found.

The low bug was found because the method invocation to dynamically refresh the table is not being called properly. Hence, no show appointment is not dynamically removed from no show list when added to archive list.

The 5 medium bugs were due to:
* The codes were not able to recognize a reschedule make from no show list and the normal reschedule make from the calendar.
* Patient is added successfully to the queue but on second click it will cause an error. This is because the action button was not disabled successfully.
* Patient is not removed from the no show list when the appointment is successfully rescheduled.
* Cannot revert action of adding patient to queue
* No distinction was made to patient record that is added to no show and patient record that is added to queue.
Used the planned debugging time in the sprint. Team was able to fix all the bugs within the scheduled time.
8 57 7 low bugs and 5 medium bugs and 3 high severity bugs found.

Team stopped all current development then and resolved the bugs immediately. All bugs were fixed within the scheduled time.
9 47 2 low bugs and 4 medium bugs and 4 high severity bugs found.

Team stopped all current development then and resolved the bugs immediately. All bugs were fixed within the scheduled time.
10 20 2 low bugs and 1 medium bug and 1 high severity bugs found.

Used the planned debugging time in the sprint. Team was able to fix all the bugs within the scheduled time.
11 21 1 low bug and 5 medium bugs found.

Used the planned debugging time in the sprint. Team was able to fix all the bugs within the scheduled time.
12 30 4 low bugs and 4 medium bugs and 1 high severity bug found.

Used the planned debugging time in the sprint. Team was able to fix all the bugs within the scheduled time.