This week the subject came up again at a customer: “why do we need a separate bug field for Priority and Severity…”?
To make a long story short, the Dev Lead kept saying that he only looks at the Priority field and so we shouldn’t waste time writing down the Severity; then (to emphasize his point) he said that 90% of the time Priority and Severity have the same value and where they don’t it was only since the QA wanted to exaggerate the severity of some Bugs…
Without getting into the outcome of the discussion, I think that in most projects Priority and Severity should be 2 separate fields.
1. Severity refers to the Bug and how it affects the User’s interaction with the Application. Priority refers to the Project and how urgent it is to solve the Bug in the context of the work been done.
2. Severity is objectively set based on the direct and indirect repercussions of the bug, together with the probability of its occurrence. Priority is set based on changing project factors such as where is development and QA focused at the present time, how many more defects do we think we will fix before release, how important is this bug for a specific customer or objective, etc.
3. Severity is usually a static field, the only reason to modify it would be if we learn something new about the bug (such as possible workarounds, additional user scenarios, etc), or if the functionality of the application changes in ways that affects the bug.
Priority should be dynamic, to be revised and updated as the project progresses and we want to shift the focus of our efforts into specific product areas, and as we start reaching the end of the schedule and we need to make sacrifices about what will be fixed for the current version and what will be pushed to future ones.
The Priority of a bug should be set and modified in agreement by the project stakeholders based on the strategic and tactical decisions of the project. In most cases, this is done during a regular (daily, weekly, etc) meeting where they review and evaluate the open bugs in the system.
An additional gain of correctly working with both fields is that as we start a new project and we need to review all the bugs left opened from the previous one we have a way to categorize and organize our list based on its objective severity.
Having said all the above in some cases, and specially on small or simple projects, one field will do for both values. This happens mainly when all bugs are fixed based on their Severity and thus Priority becomes redundant.
Regardless of how you organize your Defects and/or your Project. You need to make sure to capture as much information for the bug as possible. This will help you in your present project, and it will also provide you with valuable information for future ones.
http://qablog.practitest.com/2008/10/severity-vs-priority-of-a-bug/
To make a long story short, the Dev Lead kept saying that he only looks at the Priority field and so we shouldn’t waste time writing down the Severity; then (to emphasize his point) he said that 90% of the time Priority and Severity have the same value and where they don’t it was only since the QA wanted to exaggerate the severity of some Bugs…
Without getting into the outcome of the discussion, I think that in most projects Priority and Severity should be 2 separate fields.
1. Severity refers to the Bug and how it affects the User’s interaction with the Application. Priority refers to the Project and how urgent it is to solve the Bug in the context of the work been done.
2. Severity is objectively set based on the direct and indirect repercussions of the bug, together with the probability of its occurrence. Priority is set based on changing project factors such as where is development and QA focused at the present time, how many more defects do we think we will fix before release, how important is this bug for a specific customer or objective, etc.
3. Severity is usually a static field, the only reason to modify it would be if we learn something new about the bug (such as possible workarounds, additional user scenarios, etc), or if the functionality of the application changes in ways that affects the bug.
Priority should be dynamic, to be revised and updated as the project progresses and we want to shift the focus of our efforts into specific product areas, and as we start reaching the end of the schedule and we need to make sacrifices about what will be fixed for the current version and what will be pushed to future ones.
The Priority of a bug should be set and modified in agreement by the project stakeholders based on the strategic and tactical decisions of the project. In most cases, this is done during a regular (daily, weekly, etc) meeting where they review and evaluate the open bugs in the system.
An additional gain of correctly working with both fields is that as we start a new project and we need to review all the bugs left opened from the previous one we have a way to categorize and organize our list based on its objective severity.
Having said all the above in some cases, and specially on small or simple projects, one field will do for both values. This happens mainly when all bugs are fixed based on their Severity and thus Priority becomes redundant.
Regardless of how you organize your Defects and/or your Project. You need to make sure to capture as much information for the bug as possible. This will help you in your present project, and it will also provide you with valuable information for future ones.
http://qablog.practitest.com/2008/10/severity-vs-priority-of-a-bug/
No hay comentarios.:
Publicar un comentario