As pointed out earlier just severity doesn't solve all of issues about what bugs have to be fixed before shipping. One suggestion was priority which is fine except that it begs the question, "Who gets to decide the priority?" What I've used as the second 'axis' is a property we called "visibility."
Imagine that your code crashes on alternate Thursdays when there is a full moon and the user leans on the space bar with their left elbow. Also imagine that your software misspells the Client's name on the opening screen. Which bug is more visible? Which bug should be fixed first? If all one cares about is severity it would be the first bug. Depending upon who is setting the priority, it could still be the first bug. But I'm going to claim that while in an ideal world the customer wants both fixed if they have to choose, they will choose the second.
So to get back to the first issue, "a standard for what constitutes a sev 1 bug," most of the other messages have a good suggestions. Pick your favorite and get the dev & test groups to buy in. Then work on the second axis, (visibility or priority or whatever makes sense in your environment.) Finally remember the roles, it's test's job to document as many defects as possible, it's dev's job to develop the code and fix whatever is possible within schedule and budget constraints and it's evil management's job to decide what those constraints are. Anything longer and potentially more profitable than "Hello, World" has bugs, the key is accurately knowing and assessing them so that a good decision about shipping can be made.
Random number generation is too important to be left to chance.
MAK
As pointed out earlier just severity doesn't solve all of issues about what bugs have to be fixed before shipping. One suggestion was priority which is fine except that it begs the question, "Who gets to decide the priority?" What I've used as the second 'axis' is a property we called "visibility."
Imagine that your code crashes on alternate Thursdays when there is a full moon and the user leans on the space bar with their left elbow. Also imagine that your software misspells the Client's name on the opening screen. Which bug is more visible? Which bug should be fixed first? If all one cares about is severity it would be the first bug. Depending upon who is setting the priority, it could still be the first bug. But I'm going to claim that while in an ideal world the customer wants both fixed if they have to choose, they will choose the second.
So to get back to the first issue, "a standard for what constitutes a sev 1 bug," most of the other messages have a good suggestions. Pick your favorite and get the dev & test groups to buy in. Then work on the second axis, (visibility or priority or whatever makes sense in your environment.) Finally remember the roles, it's test's job to document as many defects as possible, it's dev's job to develop the code and fix whatever is possible within schedule and budget constraints and it's evil management's job to decide what those constraints are. Anything longer and potentially more profitable than "Hello, World" has bugs, the key is accurately knowing and assessing them so that a good decision about shipping can be made.
MAK