http://jrothman.com/blog/mpd/2005/02/managing-defects-by-severity-and-frequency.html Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk. Tue, 27 Jul 2010 17:25:03 +0000 hourly 1 http://wordpress.org/?v=3.0 http://jrothman.com/blog/mpd/2005/02/managing-defects-by-severity-and-frequency.html/comment-page-1#comment-56 Benjamin Yoskovitz Sat, 05 Feb 2005 02:38:41 +0000 http://jrothman.com/blog/mpd/?p=8186#comment-56 I just found your blog and this is the first post that caught my eye. Frequency is an interesting measurement for the overall importance of a bug, it's definitely something I take into consideration. I see its effectiveness in combination with severity (as you've defined it). For example, there may be a lower severity bug but its frequency starts to raise the overall importance of fixing that bug. Its measuring the difference in importance to your business between 1 customer that's work is interrupted due to a bug, versus 50 customers that are annoyed by a bug (but that bug isn't stopping their work). Frequency of a bug likely means more support calls/emails that you need to handle, and more time/money spent handling customers. Suddendly that small, frequently occuring bug is a much more serious issue. I just found your blog and this is the first post that caught my eye. Frequency is an interesting measurement for the overall importance of a bug, it’s definitely something I take into consideration.
I see its effectiveness in combination with severity (as you’ve defined it). For example, there may be a lower severity bug but its frequency starts to raise the overall importance of fixing that bug. Its measuring the difference in importance to your business between 1 customer that’s work is interrupted due to a bug, versus 50 customers that are annoyed by a bug (but that bug isn’t stopping their work).
Frequency of a bug likely means more support calls/emails that you need to handle, and more time/money spent handling customers. Suddendly that small, frequently occuring bug is a much more serious issue.

]]> http://jrothman.com/blog/mpd/2005/02/managing-defects-by-severity-and-frequency.html/comment-page-1#comment-59 Michael Ewins Fri, 04 Feb 2005 02:29:41 +0000 http://jrothman.com/blog/mpd/?p=8186#comment-59 This reminds me of Jakob Nielsen's essay on rating severity of usability problems. He uses three factors to do this: frequency; impact; and persistence. Here is a link to the essay... http://www.useit.com/papers/heuristic/severityrating.html This reminds me of Jakob Nielsen’s essay on rating severity of usability problems. He uses three factors to do this: frequency; impact; and persistence.
Here is a link to the essay… http://www.useit.com/papers/heuristic/severityrating.html

]]> http://jrothman.com/blog/mpd/2005/02/managing-defects-by-severity-and-frequency.html/comment-page-1#comment-58 James A. Ward Thu, 03 Feb 2005 21:35:28 +0000 http://jrothman.com/blog/mpd/?p=8186#comment-58 The frequency analysis sounds like a simplified version of a Pareto Analysis, also known as the 80-20 rule. This says that 20 percent of your problems will result in 80 percent of the occurrences of problem tickets. This analysis is fairly common and should be included in a prioritization system. The frequency analysis sounds like a simplified version of a Pareto Analysis, also known as the 80-20 rule. This says that 20 percent of your problems will result in 80 percent of the occurrences of problem tickets. This analysis is fairly common and should be included in a prioritization system.

]]> http://jrothman.com/blog/mpd/2005/02/managing-defects-by-severity-and-frequency.html/comment-page-1#comment-57 Henrik Johansson Thu, 03 Feb 2005 13:08:37 +0000 http://jrothman.com/blog/mpd/?p=8186#comment-57 In our organization, the priority of a bug is king. This value is set by the change control board (which handles defects and change reuqests) and the developers fix accordingly. Work planning in other words. Severity is something that we testers really don't know what to do with. Now most bugs are "normal" and then a few are above or below signalling how severe we think it is. BUT - how much information should we use when setting the severity. We know things about business value etc and when using that we may approach the priority decision instead. This frequency factor is interesting and something we use when setting the priority of test cases. Maybe there is a good way to use it for defect management as well but it is not easy... In our organization, the priority of a bug is king. This value is set by the change control board (which handles defects and change reuqests) and the developers fix accordingly. Work planning in other words.
Severity is something that we testers really don’t know what to do with. Now most bugs are “normal” and then a few are above or below signalling how severe we think it is. BUT – how much information should we use when setting the severity. We know things about business value etc and when using that we may approach the priority decision instead.
This frequency factor is interesting and something we use when setting the priority of test cases. Maybe there is a good way to use it for defect management as well but it is not easy…

]]>