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

Getting To Yes

"Getting To Yes: Negotiating Agreement Without Giving In" de Roger Fisher y William Ury es un clásico libro de negociación donde los autores nos explican su método para maximizar los resultados en todas las negociaciones que encaremos en nuestra vida. 

Generalmente en las negociaciones cada lado toma una posición, pelea por ella y da concesiones hasta llegar a una solución de compromiso que conforma pero no deja contentos a ambas partes. Con este método nunca se llega al mejor resultado posible y se corroe la relación con la persona con quien negociamos.

Un punto a resaltar del libro es que está repleto de ejemplos, desde negociaciones políticas históricas a negociaciones del día a día en una pareja, que enriquecen la teoría.

Un ejemplo simple del libro son dos hermanas peleando por una naranja. Ambas la quieren y terminan negociando cortar la mitad para cada una. Luego volveremos a este ejemplo.

El método que plantean los autores es simple:

1. Separar la gente del problema, la idea es no dañar la relación con la persona que tenemos enfrente.
2. Enfocarse en los intereses, no es posiciones. Pensar en el problema en cuestión, preguntar, encontrarle la vuelta.
3. Inventar opciones para que ambas partes se vean beneficiadas. La idea es que la negociación no sea combativa, ambas partes tienen que exponer todos los datos que tienen del problema para que la negociación se vuelva un trabajo en conjunto entre ambas partes, con el objetivo de lograr el mejor resultado.
4. Insistir en usar criterios objetivos. Buscar precedente, estándares, expertos, todo ayuda para lograr un resultado más justo.

El concepto es simple y lógico, hay que ver a la persona con la que negociamos como un aliado y trabajar en conjunto para lograr el mejor resultado para ambas partes. Continuando con el ejemplo, una hermana quería solo la cascara de la naranja para hacer una torta, la otra quería comerse el contenido. En la negociación original tomaron la posición de que querían la naranja, sin exponer sus necesidades, y una tiro la cascara de su mitad y la otra el interior de la naranja de la suya.

Les recomiendo el libro, es entretenido, corto y está lleno de ejemplos.