Diferenciando la Prioridad y la Severidad de un Defecto

Aunque sean dos atributos distintos, mucha gente se confunde entre la severidad y la prioridad de un defecto. Uno puede llegar a preguntarse, ¿Qué es más importante, un defecto con prioridad alta o severidad alta? Antes de responder la pregunta, veamos que nos dice la teoría sobre cada uno de estos atributos.

La prioridad viene del negocio. En este caso uno se pregunta cuán importante es para el negocio que se arregle este defecto. La severidad es técnica. La mayoría de las veces un defecto de alta severidad se convierte en un defecto de alta prioridad, pero no siempre. Hay casos que defectos de alta severidad tienen una prioridad baja y viceversa: defectos de baja severidad son de alta prioridad.

La severidad, además de ser un atributo técnico, está enfocada en la experiencia del usuario con la aplicación. Asignar la severidad de un defecto es simple, los testers lo pueden hacer teniendo conocimiento del proyecto. Sin embargo, asignar la prioridad es más difícil. La severidad es uno de los factores que se toma en consideración cuando se asigna la prioridad de un defecto. Otros de los factores son: cuanto tiempo queda para salir a producción, cuánto tiempo lleva resolver el defecto, quien está disponible para arreglarlo, cuán importante es para el negocio arreglarlo, cual es el impacto, cual la probabilidad de ocurrencia y cuál es el grado de efectos colaterales que puede causar el defecto.

En muchas organizaciones, defectos de cierta severidad deben ser al menos de cierta prioridad. Por ejemplo, los defectos que llevan a cerrar el sistema o a le hacen perder datos al usuario tienen que ser prioridad uno si se puede reproducir siempre. S pasa el 1% de las veces, seria ultima prioridad, manteniendo la severidad alta. Una falta de ortografía en la página principal de un sitio web es un defecto de severidad baja, es muy fácil de arreglar, pero para el negocio su prioridad es alta ya que afecta la imagen de la compañía. 

Otra forma de verlo es la siguiente: la prioridad es relativa y la severidad es absoluta. La prioridad puede cambiar con el tiempo, dependiendo el calendario y que otros defectos hay en la lista. La prioridad puede pensarse como el orden con el que los defectos tienen que ser resueltos en un cierto momento. En cambio, la severidad es un análisis de técnico del bug, sin importar el calendario.

Microsoft usa una escala de cuatro puntos para describir la severidad de los defectos y una escala de tres puntos para describir su prioridad:

Severity

1. Bug causes system crash or data loss.
2. Bug causes major functionality or other severe problems; product crashes in obscure cases.
3. Bug causes minor functionality problems, may affect "fit and finish".
4. Bug contains typos, unclear wording or error messages in low visibility fields.

 
Priority

1. Must fix as soon as possible.  Bug is blocking further progress in this area.
2. Should fix soon, before product release.
3. Fix if time; somewhat trivial. May be postponed.

Para cerrar el artículo, puede valer la pena no utilizar el campo severidad. Son pocas las situaciones donde sirve tenerlo, contrastando con el tiempo y esfuerzo que se necesita para definir el valor y utilizarlo. Si a uno le piden utilizar el valor de severidad, pregunte la razón.

Fuentes:

• http://www.softwaretestingclass.com/what-is-difference-between-priority-and-severity/
• http://quality-intelligence.blogspot.com.ar/2010/08/bug-severity-vs-priority.html
• http://c2.com/cgi/wiki?DifferentiatePriorityAndSeverity
• http://geekswithblogs.net/srkprasad/archive/2004/08/20/9961.aspxhttp://www.stickyminds.com/sitewide.asp?ObjectId=6323&Function=DETAILBROWSE&ObjectType=COL