IS480 Team wiki: 2010T1 The Green Reapers: Bug Tracking
Bug Tracking Metric
|Severity Level||Description||Action Plan|
|4||A crash or anything that loses persistent data||Solve bug immediately as it will jeopardize the development of other functions. Do not continue to next iteration until bug is solved.|
|3||A feature that doesn't work as planned||Solve bug immediately as it will jeopardize the development of other functions.|
|2||An aspect of a feature that doesn't work||Solve bug immediately|
|1||Purely cosmetic problems||Solve bug as soon as possible. Still proceed on development of next function according to schedule.|
Intense regression testing is commenced at the end of every iteration of the project to ensure newly implemented functions and features are working as intended and existing functionality are not affected.
Our team makes use of google docs excel sheet to record and report bugs we encountered. Google docs provide an excellent way of sharing a persistent copy of the list of bugs and issues with the entire team. This suits best for the scale of our project as it is hassle free and quick to setup.
At the end of each testing phase, members of the respective sections of the team, namely IVR,DA and CMS will access the document and update the status and action taken.
With the information recorded a bug severity index to calculated to track and analyze our bugs progress over each iteration.
We notice a falling trend in the bugs as we move on from iteration 3. Iteration 3 was the phase where we engaged in very first round of intensive UAT. This was where majority of severe application breaking bugs were discovered and fixed.
In Iteration 4, we still sees a number of bugs discovered due to new bugs arising from the implementation of fixes in iteration 3, there were however half as little in number and severity.
In Iteration 5,6 and 7 we focused more on usability testing with both Users and IRRI and the bugs encountered were of low severity as they consist of mostly interface and usability issues.