In the formal description of the problem, inter alia, to determine the severity and priority of the problem.
Severity describes how serious the problem in terms of loss of functionality. This classification should make a tester opens bug in the database.
Priority orders the order in which bugs Stalling programmer. The tester can not and should not interfere in this process. Suppose that the manager will of the programmer. He knows better than anyone and should be engaged in his team. In particular, and who will have to fix the problem.
It is important to understand the difference between these two types of classification and not confuse them.
I have worked in six software companies – small startups and industry giants such as Lotus and Borland. On the one hand, every company has its own views on the classification system as to priority, and in severity. But, curiously, despite the differences in the used category names and their numbers, all we can say about the severity of perfectly fit into four categories:
Critical – problems that can not be bypassed even by the user using a call to TechSupport. There is no way get out along the way and finish the job. There is no workaround. Another common name for this group – fatal. This category includes all problems that lead to loss of information – data corruption, crash, hang (system hang), and so on.
Serious – serious functional impairment, which can in principle get around and complete the operation in progress.
Minor – This is something that does not prevent you to work, but it creates a small inconvenience or get on your nerves. We are not talking about the improvement of the product. We are talking about problems at the level of standards or technical specifications. These include primarily the problem of user interface, but not only.
Enhancement – here we mean everything that is not a violation of the requirements specification, but will help make the product better, more convenient to use. Sometimes use the word Suggestion.
You can have more than four categories, but they do not add much value. When I came to work at Lotus, the first thing I reached into the Bug Tracking System, and began to torture the manager why there eight categories and where the boundary between them. Categories do not have names, and went by the numbers – 1, 2, 3 and so on up to 8. That "scratched turnip" and he said "The first three categories will be repaired, and the other does not. So, use your intuition and not to strain on the matter." As we can see, the categories was still four – 1, 2, 3, and all the rest.
A word about the ratio of severity and priority. Let’s look at this problem:
When you save a message box pops up asking "Do you really want to save that file?" The user presses the button YES, a message pops up again. He presses the button again, but the message it has. After unsuccessful attempts dyasyatka user calls in and asks TechSupport what it is. He cultural explain that this is a known problem and all you need – is to continue to press a button. And really – on the 20th or so you saved the file. The problem comes in the category of Serious but not Critical, because it has a workaround, that is, you can get out. From the perspective of project manager, the same problem will be priority High (believe that we have high, medium, low), because such problems the company will be ridiculed.
Thus, to the highest level of priority may well relate to the problem is not the highest level of severity. Conversely, some exotic crash, which in real life is extremely difficult to come across, may have a relatively low priority in fixing a problem than in the interface that immediately catches the eye.