is to the testing schedule, and how urgent it is that this issue be resolved. This is indeed vital information to have when identifying issues with software. But while the severity and priority fields serve the purpose of communicating this information, they do not do it in the most effective and unambiguous way possible.
Think of the following type of problem: a spelling error on a user-interface screen. What severity does this issue deserve? Well, judging from our canned definitions, it would seem that this is a low-severity item. After all, the server doesn't crash due to a spelling error. But is this truly a low-severity problem? A spelling error will probably not hinder a customer's ability to use the system, but it greatly affects the customer's perception of the company that created the product and of the quality of the product. So from customer-relations and corporate-image points of view, the severity of this type of issue is indeed high. But the severity field doesn't allow us to express that properly. So the need for the priority field becomes apparent. The priority field does allow product management to define this issue as high priority, but this creates the case where something is low severity but high priority. To me, this is an ambiguous duality. How exactly does this issue stack up against the others in the system? When should a developer look at this issue?
Let's consider another case: the anomalous server crash. We've all seen this type of issue. A server crash that occurs on the first full moon of every leap year but that is not reproducible by any human means on a consistent basis. So how would this issue be categorized within the defect tracking system? Well, since it is a server crash, many would argue it should be a high-severity issue. After all, the system is inoperable until the server is restarted. But what is the impact to the customer? In this case, the impact is quite small. Since the customer may never see this issue present itself at all in a production environment, it would be given a low priority by product management. Here then is another case where an issue has an ambiguous duality: a high-severity issue that is not a high-priority issue.
A Modest Proposal
I recommend eliminating the Severity and Priority fields and replacing them with a single field that can encapsulate both types of information: call it the Customer Impact field. Every piece of software developed for sale by any company will have some sort of customer. Issues found when testing the software should be categorized based on the impact to the customer or the customer's view of the producer of the software. In fact, the testing team is a customer of the software as well. Having a Customer Impact field allows the testing team to combine documentation of outside-customer impact and testing-team impact. There would no longer be the need for Severity and Priority fields at all. The perceived impact and urgency given by both of those fields would be encapsulated in the Customer Impact field.
Let's consider our previous examples. In the first example, the spelling error on the user interface screen was rated as low severity by the testing team, but as high priority by product management. This ambiguous duality disappears when the Customer Impact field is used in place of Severity and Priority. This particular issue would have a high impact on the customer's view of the company that produced the software and the quality systems in place at that company. Therefore, this issue would