Cuando se reporta un defecto, el equipo necesita decidir qué tan grave es y cuándo debe corregirse. Para eso se usan dos conceptos importantes: severidad y prioridad.
También es necesario hacer seguimiento del defecto desde que se detecta hasta que se cierra. Ese recorrido se conoce como ciclo de vida de un defecto.
En este tema veremos la diferencia entre severidad y prioridad, ejemplos de clasificación y los estados habituales por los que pasa un defecto.
La severidad indica qué tan grave es el impacto del defecto en el sistema, la funcionalidad, los datos, la seguridad o el usuario.
La severidad responde preguntas como:
La severidad describe impacto técnico o funcional. No necesariamente indica cuándo se corregirá.
La prioridad indica qué tan urgente es corregir un defecto. Se relaciona con planificación, negocio, fechas, recursos y decisiones del equipo.
La prioridad responde preguntas como:
La prioridad puede cambiar según contexto, fecha de entrega o impacto de negocio.
La diferencia principal es:
Un defecto puede tener alta severidad y baja prioridad, o baja severidad y alta prioridad. Por eso no conviene usarlas como sinónimos.
| Concepto | Enfoque | Ejemplo de pregunta |
|---|---|---|
| Severidad | Impacto del defecto. | ¿Qué daño produce si ocurre? |
| Prioridad | Urgencia de corrección. | ¿Cuándo debemos corregirlo? |
Cada equipo puede definir sus propios niveles, pero una clasificación habitual es:
| Severidad | Descripción | Ejemplo |
|---|---|---|
| Crítica | Impide usar el sistema o afecta funciones esenciales, datos, seguridad o dinero. | El sistema permite pagar sin descontar stock o expone datos privados. |
| Alta | Afecta una funcionalidad importante, pero existe alguna alternativa o el sistema no queda totalmente inutilizable. | No se puede recuperar contraseña, pero el login normal funciona. |
| Media | Afecta una funcionalidad secundaria o un caso importante pero no crítico. | Un filtro de búsqueda devuelve resultados incompletos. |
| Baja | Impacto menor, visual o de texto, sin afectar operación principal. | Error ortográfico en un mensaje informativo. |
La prioridad suele clasificarse de forma similar, pero con enfoque en urgencia:
| Prioridad | Descripción | Ejemplo |
|---|---|---|
| Urgente | Debe corregirse de inmediato o antes de continuar. | Defecto que bloquea la publicación de la versión. |
| Alta | Debe corregirse en la entrega actual. | Problema en flujo que el cliente usará esta semana. |
| Media | Debe corregirse, pero puede planificarse sin urgencia inmediata. | Falla en funcionalidad secundaria. |
| Baja | Puede esperar a una versión futura. | Ajuste visual menor en una pantalla poco usada. |
Este caso es el más claro: el defecto es grave y debe corregirse pronto.
Ejemplos:
Normalmente estos defectos bloquean una entrega o requieren atención inmediata.
A veces un defecto puede ser grave, pero no urgente por el contexto.
Ejemplo:
El impacto potencial es alto, pero la corrección puede planificarse si no afecta la entrega actual. Esto no significa ignorarlo, sino gestionarlo con el tiempo adecuado.
También puede ocurrir que un defecto no sea grave técnicamente, pero deba corregirse pronto por razones de negocio, imagen o fecha de entrega.
Ejemplos:
La severidad puede ser baja, pero la prioridad alta por contexto.
La severidad suele ser propuesta por quien reporta el defecto, especialmente si observa el impacto funcional o técnico. La prioridad suele definirse en conjunto con responsables del producto, negocio, líderes técnicos o gestión del proyecto.
En la práctica:
Lo importante es que los criterios sean compartidos y no dependan solo de opiniones aisladas.
El ciclo de vida de un defecto es el recorrido que sigue desde que se detecta hasta que se cierra. Cada equipo puede usar estados diferentes, pero la lógica general suele ser similar.
Un ciclo típico puede ser:
También pueden existir estados como Rechazado, Duplicado, No reproducible, Diferido o Reabierto.
| Estado | Significado |
|---|---|
| Nuevo | El defecto fue registrado y espera revisión. |
| Asignado | Se asignó a una persona o equipo para analizarlo. |
| En análisis | Se investiga causa, alcance o reproducibilidad. |
| En corrección | Se está desarrollando la solución. |
| Corregido | La corrección fue implementada y está lista para probar. |
| En retest | QA vuelve a probar para confirmar la corrección. |
| Cerrado | La corrección fue validada o se resolvió según acuerdo. |
Además de los estados principales, pueden existir estados especiales:
Estos estados deben usarse con explicación. Por ejemplo, cerrar como "No reproducible" sin pedir más información puede ocultar defectos reales.
Cuando un defecto se marca como corregido, QA o quien corresponda debe volver a probar el caso. Esto se conoce como retest.
Durante el retest se verifica:
Si la corrección funciona, el defecto puede cerrarse. Si no funciona, se reabre con nueva evidencia.
Un defecto se reabre cuando la corrección no resolvió el problema o el problema reaparece.
Al reabrir conviene agregar:
Reabrir no debe verse como conflicto. Es parte normal del ciclo cuando una corrección no fue suficiente.
Este ejemplo muestra cómo severidad, prioridad y estados trabajan juntos.
La gestión de defectos permite generar información útil para decidir. Por ejemplo:
Estos datos ayudan a evaluar riesgo, no solo actividad.
Al gestionar defectos, algunos errores frecuentes son:
Para gestionar defectos de forma clara conviene:
Severidad, prioridad y ciclo de vida permiten gestionar defectos de manera ordenada. La severidad ayuda a entender impacto; la prioridad ayuda a decidir cuándo corregir; el ciclo de vida permite hacer seguimiento hasta la resolución.
Un defecto no termina cuando se reporta ni cuando se corrige en código. Termina cuando se valida la corrección, se actualiza su estado y se considera cerrado con evidencia suficiente.
En el próximo tema estudiaremos pruebas de regresión, humo y sanidad, tres prácticas muy usadas para validar versiones y cambios de forma eficiente.