Severity is in the eye of the beholder, and thus should always be classified in terms of its impact on the users of the software, as in
Severity 1: Essential functionality inoperative, no presvention or workaround possible.
Severity 2: Essential functionality inoperative, workaround or limited functionality use possible.
Severity 3: Reliability of essential functionality compromised, no workaround possible.
Severity 4: Reliability of essential functionality is compromised, workaround is possible.
Severity 5-8: repeat descriptions 1-4 for non-essential functionality.
When prioritizing and resourcing fixes for defects classified as described above, a separate independent assessment needs to be made as to the scope, complexity and risk of the fix(es) required, but I must emphasize that these are NOT related to the severity of the defect.
Also, I do not believe that error messages should attempt to characterize the severity the error condition they are reporting. It is to be left to the user to determine what constitutes essential vs. non-essential functionality, or whether a workaround is possible or not. EVERY error message should, however, directly contribute to giving the user/support enough information to correctly and consistently correct the problem. Sepcifically, every error message should report:
1) date/time
2) the identity of the software reporting the error
3) the exact operation that was attempted (report method names and arguments wherever possible)
4) the system-level completion status of that operation (report errno or its equivalent at a minimum)
5) what the software intends to do now, eg. use a default value, retry, ask the user for a better input value, abort, etc.)
Way to much otherwise well written software has been rendered useless by poorly thought out error handling and messages. Shame on us.
Slashdot Mirror
just because I can
Severity is in the eye of the beholder, and thus should always be classified in terms of its impact on the users of the software, as in
Severity 1: Essential functionality inoperative, no presvention or workaround possible.
Severity 2: Essential functionality inoperative, workaround or limited functionality use possible.
Severity 3: Reliability of essential functionality compromised, no workaround possible.
Severity 4: Reliability of essential functionality is compromised, workaround is possible.
Severity 5-8: repeat descriptions 1-4 for non-essential functionality.
When prioritizing and resourcing fixes for defects classified as described above, a separate independent assessment needs to be made as to the scope, complexity and risk of the fix(es) required, but I must emphasize that these are NOT related to the severity of the defect.
Also, I do not believe that error messages should attempt to characterize the severity the error condition they are reporting. It is to be left to the user to determine what constitutes essential vs. non-essential functionality, or whether a workaround is possible or not. EVERY error message should, however, directly contribute to giving the user/support enough information to correctly and consistently correct the problem. Sepcifically, every error message should report:
1) date/time
2) the identity of the software reporting the error
3) the exact operation that was attempted (report method names and arguments wherever possible)
4) the system-level completion status of that operation (report errno or its equivalent at a minimum)
5) what the software intends to do now, eg. use a default value, retry, ask the user for a better input value, abort, etc.)
Way to much otherwise well written software has been rendered useless by poorly thought out error handling and messages. Shame on us.