“Crítico”, como se usa en el discurso cotidiano en el trabajo, puede significar crítico para el sistema o crítico para el negocio. En el campo del aseguramiento de la calidad del software, la gravedad y la prioridad son perspectivas diferentes. Esta diferenciación también está respaldada por los estándares de la industria en pruebas de software, CSTE y la Junta Internacional de Calificación de Pruebas de Software (ISTQB).
En esta respuesta, la criticidad se basa solo en el nivel de gravedad y no necesariamente en el nivel de prioridad, por lo que mi respuesta será diferente de la mayoría de las otras respuestas donde se combinan los dos conceptos (lo que hace que los criterios sean difíciles de definir como un estándar objetivo que no No cambie la “criticidad” de un error con el tiempo).
Antes de indicar la respuesta, aquí hay definiciones y ejemplos que diferencian los dos conceptos:
Definiciones
La gravedad es el nivel de interrupción del uso del sistema causado por el error. Está determinado por los atributos medibles del defecto en términos de funcionalidad en comparación con los objetivos generales del proyecto. La base de la categorización tiene estándares específicos que el evaluador debe tener plenamente en cuenta porque no está sujeto a opinión y no cambia con el tiempo.
Niveles de gravedad
1 – Crítico / Showstopper: el único enfoque de la pregunta (la respuesta a esto se proporciona en la última parte)
2 – Alto / Mayor
3 – Medio
4 – Menor / Bajo
5 – Trivial / Cosmético (generalmente combinado con Menor / Bajo)
La prioridad es el nivel de urgencia de la corrección de errores, en relación con los objetivos y prioridades del proyecto establecidos durante un período de tiempo determinado. El nivel de prioridad para un error puede cambiar con el tiempo según la situación. Los factores del negocio, que son específicos del cronograma / del recurso, son subjetivos y su categorización puede estar más allá del alcance del probador y debe ser decidida por el gerente del proyecto.
Niveles de prioridad
P1: lo más urgente y debe repararse lo antes posible
P2 – versión actual
P3 – próximo lanzamiento
P4: algún tiempo después del próximo lanzamiento
P5: puede entretenerse cuando hay una revisión del sistema
Ejemplos para ilustrar la diferencia entre gravedad y prioridad:
Ejemplo # 1 – un defecto con baja gravedad pero con alta prioridad :
Error tipográfico que aparece prominentemente, como el nombre de la empresa y el número de teléfono. Según la percepción del cliente, esto es urgente e importante, pero no impide otras funciones en el sistema.
Ejemplo # 2 – un defecto con alta severidad pero con baja prioridad :
Un error importante al que solo acceden unos pocos usuarios. Aunque es grave, se estima que solo unos pocos usuarios usarán la función específica y existe una alta posibilidad de que no se use pronto.
Las diferencias entre la gravedad y la prioridad se concilian a través de lo siguiente:
- El gerente del proyecto clasifica los defectos. Al determinar el nivel de prioridad, la gravedad se utilizará junto con los otros factores enumerados anteriormente.
- Las actividades de los programadores y probadores se basarán únicamente en el nivel de prioridad (entre los ejemplos anteriores, el Ejemplo n. ° 1 debe solucionarse primero)
Factores que no deberían afectar la gravedad del error (es decir, si el error es crítico para el sistema) pero pueden afectar la prioridad del error:
1) Problemas que no están relacionados con la descripción de la destructividad del error en el proyecto
- explicación técnica sobre la naturaleza del error (por ejemplo, es un problema técnico conocido, también existía en la compilación anterior)
- complejidad de la corrección de errores
- dependencia del error a otro error
- frecuencia, probabilidad de encontrar el error o usar la función afectada
- existencia, cantidad y gravedad de los otros errores en el mismo proyecto
- reacción emocional del usuario final / parte interesada; cantidad estimada de quejas de clientes
2) Problemas comerciales y decisiones que no están relacionadas con la arquitectura del sistema:
- plazo del proyecto
- urgencia percibida de la corrección de errores
- tiempo y costo adicionales estimados para investigar, corregir y verificar el error
- cantidad de desviación del cronograma del proyecto
- sistema de programación de los recursos que comparten múltiples proyectos
- posición de la persona que solicita la mejora / función afectada
- El tipo de persona que se vería afectada por el error (por ejemplo, clientes externos frente a empleados internos)
Para responder la pregunta, estas son las únicas condiciones para marcar un error como Crítico / Showstopper:
- bloquea las unidades principales del sistema, bloquea la capacidad de continuar usando el producto
- hace que el producto se considere no operativo
- puede hacer que la aplicación sea inutilizable
- evita el logro de objetivos comerciales importantes, lo que resulta en fallas a gran escala (por ejemplo, menos ganancias, más gastos).
- afecta la funcionalidad o los datos críticos en la característica principal que afecta gravemente a los usuarios
- la solución es difícil (por ejemplo, no es obvia o es difícil de usar) o inexistente
