Once a large number of bugs exist, a strategy can be used (or not) to resolve them unless resources exist to fix them all within a reasonable amount of time. It could be FIFO, ascending level of effort, squeaky wheel/vote, product centric (e.g.,fix all reported Duet issues) or focused on core functionality/features. I have listed these approaches in the reverse order of how I believe they impact customer perception of the software. A weighted approach could be taken such as 80% core functionality/ 20% low level of effort.
If a bug sits unresolved long enough, it can be rationalized as unneccessary to fix because users have lived so long with it. When debugging a new release, goals can be set such as 70% of new bugs resolved prior to release or 100% of critical bugs resolved prior to release. If the 70% resolved are easy bugs or the critcal bugs are mis-characterised, well... Regression testing helps discover when fixing a bug has side effects. When a fix to a bug gives rise to another, the bug count does not diminish. -- DotSystem ------------------------------------------------------------------------ DotSystem's Profile: http://forums.slimdevices.com/member.php?userid=15213 View this thread: http://forums.slimdevices.com/showthread.php?t=68947 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
