¿Cómo priorizas testing por riesgo?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Las pruebas basadas en riesgo gastan el esfuerzo limitado donde un fallo dolería más y es más probable. Cada funcionalidad o área recibe una puntuación de probabilidad según complejidad del cambio, churn del código, historial de defectos, tecnología nueva y familiaridad del equipo, y una de impacto según alcance de usuarios, ingresos, seguridad, cumplimiento y dificultad de recuperación. El producto de ambas ordena las áreas. Las de alto riesgo reciben pruebas profundas, sesiones exploratorias, varios entornos y atención a rendimiento y seguridad; las de bajo riesgo reciben la suite de regresión automatizada y nada más. La puntuación se revisa en cada release porque ambos factores cambian.

Ejemplo

Para una release que tocaba el checkout, una página de ajustes y una reescritura del generador de PDF de facturas, la matriz de riesgo puso el checkout primero por ingresos y un cambio de concurrencia, el generador de PDF segundo por ser código nuevo sin historial y afectar a todas las facturas, y ajustes al final. El tiempo de pruebas se repartió aproximadamente 50, 35 y 15 por ciento, y la sesión exploratoria del generador de PDF encontró un bug de localización que las pruebas unitarias no habían cubierto.

Errores frecuentes

• Probar todo por igual y quedarse sin tiempo en las partes arriesgadas.
• Puntuar solo la probabilidad e ignorar que un fallo improbable en facturación es catastrófico.
• Fijar el perfil de riesgo una vez y no actualizarlo nunca a medida que cambia el código.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.