3 ms·

I've always understood that severity was supposed to be objective and defined based on the needs of the organization/project. For example: Crashing bugs and da

I've always understood that severity was supposed to be objective and defined based on the needs of the organization/project. For example: Crashing bugs and data loss are highest severity. UI bugs that prevent the user from doing something are medium severity. UI bugs that don't match the design are the lowest severity. This should obviously change for Boeing where software bugs have deadly consequences. When the bugs are filed, they're assigned a priority based on the set criteria. When the bugs are triaged, they're prioritized based on the needs of the organization/project. A typo doesn't actually make the software work less, but it's not something most organizations are okay to ship with. I don't agree that severity is different if you aren't affected by it. A design flaw in a bridge that could lead to collapse isn't low severity just because I may never cross it.

kazinator 7y ago
> UI bugs that prevent the user from doing something are medium severity. But who is "the user"? Bugs are high severity based on the principle that if we put ourselves into the shoes of a user who is affected, we understand that the user is affected badly. However, a crashing bug can be such that only a very specific, rare way of using the program makes it happen. Only a tiny minority of the users who are doing something very specific might be affected. Quite possibly, "the user" might even be actually "the", as in the one and only one who is running into it. Furthermore, the severity of a crash bug can be mitigated by whether the affected users have a workaround: can they alter their use of the program in some reasonably small way so that their workflow can continue. > A design flaw in a bridge that could lead to collapse isn't low severity just because I may never cross it. That's only so because you've made it a requirement that there is a single parameter called "severity" that may be associated with the bridge, which is a reasonable thing to do. But then we have to imagine it from the point of view of the worst case user: the user of the bridge who is on top of it when it collapses. The severity estimate comes from "how bad could it possibly be". A bridge I've never heard of in some country where I will never set foot that is on the brink of collapse is certainly not of any severity to me. Furthermore, a bridge that is in such a state can be cordoned off so that nobody may go over or under it. If nobody may use it (other than trespassers who go past the danger signs which inform them that they do so at their own risk) then there is no "worst-case user" (that we rationally care about). In that situation, the bridge's stability issue is no longer of the same severity, even though it is in the same state as before.
- RandallBrown 7y ago
  I suppose we're disagreeing on the term severity. I don't see any reason it has to to with the likelihood of encountering the bug. In my opinion severity is based on the result of something happening. Not the likelihood of it happening. > A bridge I've never heard of in some country where I will never set foot that is on the brink of collapse is certainly not of any severity to me. That's why you would set the priority low. You don't care if it's fixed, but that doesn't change the fact that it could kill someone and is quite a severe bug. I've always used severity as a way of objectively classifying bugs in order to help speed up a bug triage. It works well for that.

kazinator 7y ago

> UI bugs that prevent the user from doing something are medium severity. But who is "the user"? Bugs are high severity based on the principle that if we put ourselves into the shoes of a user who is affected, we understand that the user is affected badly. However, a crashing bug can be such that only a very specific, rare way of using the program makes it happen. Only a tiny minority of the users who are doing something very specific might be affected. Quite possibly, "the user" might even be actually "the", as in the one and only one who is running into it. Furthermore, the severity of a crash bug can be mitigated by whether the affected users have a workaround: can they alter their use of the program in some reasonably small way so that their workflow can continue. > A design flaw in a bridge that could lead to collapse isn't low severity just because I may never cross it. That's only so because you've made it a requirement that there is a single parameter called "severity" that may be associated with the bridge, which is a reasonable thing to do. But then we have to imagine it from the point of view of the worst case user: the user of the bridge who is on top of it when it collapses. The severity estimate comes from "how bad could it possibly be". A bridge I've never heard of in some country where I will never set foot that is on the brink of collapse is certainly not of any severity to me. Furthermore, a bridge that is in such a state can be cordoned off so that nobody may go over or under it. If nobody may use it (other than trespassers who go past the danger signs which inform them that they do so at their own risk) then there is no "worst-case user" (that we rationally care about). In that situation, the bridge's stability issue is no longer of the same severity, even though it is in the same state as before.

RandallBrown 7y ago
I suppose we're disagreeing on the term severity. I don't see any reason it has to to with the likelihood of encountering the bug. In my opinion severity is based on the result of something happening. Not the likelihood of it happening. > A bridge I've never heard of in some country where I will never set foot that is on the brink of collapse is certainly not of any severity to me. That's why you would set the priority low. You don't care if it's fixed, but that doesn't change the fact that it could kill someone and is quite a severe bug. I've always used severity as a way of objectively classifying bugs in order to help speed up a bug triage. It works well for that.