Glosario · Fundamentos de testing
Pruebas basadas en riesgo
En inglés: Risk-based testing
También llamado: prueba basada en riesgos, pruebas basadas en riesgos, testing basado en riesgos, estrategia de pruebas basada en riesgo
Definición
Enfoque que prioriza el esfuerzo de pruebas según el riesgo, probabilidad de fallo por impacto, para probar primero y con más profundidad las áreas más arriesgadas.
Las pruebas basadas en riesgo (risk-based testing) parten de que nunca se puede probar todo y deciden dónde invertir el tiempo según el riesgo. Cada funcionalidad o área se puntúa por su probabilidad de fallo (complejidad, cantidad de cambios, defectos anteriores, tecnología nueva) y por su impacto si falla (dinero, seguridad, datos, exposición legal, número de usuarios). Las áreas de alto riesgo reciben pruebas más tempranas, profundas y variadas; las de bajo riesgo, comprobaciones más ligeras.
Ejemplo
Una release toca cuatro áreas. Puntúa cada una del 1 al 5:
| Área | Probabilidad | Impacto | Riesgo (P x I) | Profundidad de las pruebas |
|---|---|---|---|---|
| Migración del proveedor de pagos | 5 | 5 | 25 | Funcionales completas, negativas, de integración, de rendimiento, exploratorias |
| Nuevas reglas fiscales para una región | 4 | 4 | 16 | Tests de valores límite y tablas de decisión, regresión de totales |
| Página de perfil rediseñada | 3 | 2 | 6 | Flujos principales más una comprobación visual |
| Actualización de enlaces del pie de página | 1 | 1 | 1 | Comprobación rápida |
Si el plazo se recorta dos días, ya sabes qué dejar fuera: profundidad en las filas de bajo riesgo, no en la migración de pagos.
Por qué importa
Todo plan de pruebas implica concesiones. Las pruebas basadas en riesgo las hacen explícitas y acordadas. También ofrecen una forma clara de informar del estado: “todas las áreas de alto riesgo probadas, dos riesgos medios probados en parte, quedan estos huecos conocidos” es mucho más útil para decidir una release que “83 % de los casos de prueba ejecutados”.
Errores comunes
- Puntuar en solitario. Los product owners conocen el impacto; los desarrolladores, la probabilidad. Los riesgos se puntúan en equipo.
- Puntuar una sola vez. Los riesgos cambian a medida que llega código y aparecen bugs. Un módulo que no deja de producir defectos debería subir.
- Ignorar por completo las áreas de bajo riesgo. Menos riesgo significa pruebas más ligeras, no ninguna. La regresión automatizada suele cubrir esa base.
- Confundirlo con la severidad de un bug. La severidad califica un defecto ya encontrado. El riesgo es una estimación hecha antes de probar, que se usa para decidir dónde mirar.