Respuesta.

Historia de la cuestión:

En las primeras etapas de las pruebas, los errores a menudo se corregían sin sistematización. A medida que el software se vuelve más complejo, aumenta el número de tareas y de sistemas de seguimiento de errores, surge la necesidad de una priorización adecuada, para que los recursos se dediquen primero a los problemas críticos y no a los insignificantes.

Problema:

Sin priorización, los probadores, gerentes y desarrolladores pueden perder tiempo en errores menores, dejando de lado errores críticos que pueden resultar en pérdidas financieras o de reputación, o fallos en el funcionamiento del producto.

Solución:

Implementar un sistema de niveles de prioridad:

La prioridad de los errores se divide en "Crítico", "Alto", "Medio", "Bajo" (o niveles similares).
La prioridad se determina en función del impacto del error en el negocio, el usuario y el sistema en general.
En equipos grandes, esto se hace conjuntamente con el gerente de producto.

Características clave:

Ahorro de tiempo y recursos al concentrarse en los defectos más importantes para el negocio.
Prevención de conflictos entre el equipo de QA, el desarrollo y el negocio.
Revisabilidad flexible de las prioridades a medida que la situación cambia.

Preguntas capciosas.

¿De qué depende la prioridad de un error: de la gravedad del defecto o de las prioridades del negocio?

De ambos factores. Hay errores con poca gravedad técnica, pero críticos para el negocio (por ejemplo, un error en el precio de un producto en la página de pago).

¿Todos los errores con la misma gravedad deben tener la misma prioridad?

No, es importante tener en cuenta el contexto de uso, la frecuencia de aparición y el impacto en los indicadores clave del negocio.

¿Puede cambiar la prioridad de un error con el tiempo?

Sí, a medida que avanza el proyecto, cambian los planes de lanzamiento, surgen nuevos requisitos o se recibe retroalimentación del usuario, las prioridades pueden cambiar.

Errores comunes y anti-patrones

Asignar alta prioridad a todos los errores sin distinción.
Discutir la prioridad solo dentro de QA sin la participación de PO/negocios.
Ignorar errores con prioridad "baja" que en realidad son críticos.

Ejemplo de la vida real

Caso negativo

En un sitio de comercio electrónico, se otorgó la máxima prioridad a pequeños errores de diseño estético en el seguimiento de errores, mientras que los errores relacionados con fallos en la integración de pagos se marcaron con la mínima prioridad.

Ventajas:

Rápida corrección de la parte visual del sitio.

Desventajas:

Pérdidas en ingresos debido a pagos no funcionales, a pesar de la "apariencia perfecta" de la tienda.

Caso positivo

En el equipo se definieron conjuntamente las prioridades: los errores que impedían pagos y el funcionamiento de funcionalidades vitales se marcaron como "Críticos" y se abordaron primero.