Cuando el tiempo disponible es menor que el necesario, cada decisión de qué probar primero puede marcar la diferencia entre un lanzamiento sólido y una apuesta silenciosa. Existe una fórmula de dos variables que reemplaza el instinto por números defendibles, y permite justificar ante cualquier stakeholder por qué se eligió un orden específico de pruebas.
¿Qué es el riesgo en testing y por qué se mide antes de encontrar bugs?
En sesiones anteriores se trabajó la diferencia entre severidad (daño técnico de un defecto) y prioridad (costo de negocio de esperar). Ambas clasifican defectos que ya existen. El enfoque basado en riesgo aplica la misma lógica pero hacia adelante, antes de que aparezca cualquier bug [01:00].
Riesgo en testing se define como un evento potencial con efecto negativo. Se compone de solo dos factores:
- Probabilidad: qué tan probable es que esa parte del software falle.
- Impacto: si falla, qué tan grave es el daño.
Multiplicados, producen el nivel de riesgo. Una grieta en un barandal decorativo que nadie toca representa probabilidad baja e impacto menor. La misma grieta en la viga principal de un puente por donde pasan miles de coches dispara ambos valores. Mismo material, distinta ubicación, todo cambia [01:27].
La diferencia conceptual es clara: clasificar pacientes en urgencias es triage de defectos; decidir qué barrios necesitan más ambulancias antes de que alguien se enferme es estrategia basada en riesgo.
¿Cómo estimar probabilidad e impacto sin adivinar?
Para la probabilidad existen tres señales concretas [02:20]:
- Tamaño del cambio: un módulo con diez cambios recientes y treinta bugs tiene una tasa de tres defectos por cambio. Eso es una señal de peligro inmediata.
- Complejidad: módulos con dependencias múltiples, lógica condicional anidada o integraciones externas generan más errores porque el cerebro humano solo maneja cierta complejidad a la vez.
- Historial de defectos: si un módulo produjo quince bugs mientras otros promediaron tres, algo estructural está mal: requisitos vagos, diseño deficiente o deuda técnica acumulada. El pasado predice el futuro.
Estas señales se potencian entre sí. Un cambio grande en un área compleja con historial de defectos es la tormenta perfecta.
¿Qué áreas de daño definen el impacto?
El impacto se evalúa en cuatro dimensiones [03:12]:
- Pérdida de dinero: una pasarela de pagos caída son ventas perdidas cada minuto.
- Riesgo legal: datos médicos o financieros mal manejados generan multas y demandas.
- Pérdida de datos: frecuentemente irreversible, no se arregla con un parche.
- Pérdida de confianza del usuario: el daño más duradero, porque en mercados competitivos la gente simplemente se va.
¿Cómo convertir el puntaje de riesgo en decisiones reales?
Se asignan tres niveles a cada factor: alto, medio, bajo, representados numéricamente (3, 2, 1). El producto determina el puntaje de riesgo: tres por tres da nueve, uno por uno da uno [03:47]. Como un sistema de alertas meteorológicas: tormenta muy probable y destructiva, alerta máxima; llovizna improbable, sin alerta.
El puntaje define orden y profundidad:
- Riesgo alto (puntaje 7–9): regresión completa, pruebas de seguridad y rendimiento.
- Riesgo medio (puntaje 4–6): pruebas funcionales de flujos principales.
- Riesgo bajo (puntaje 1–3): smoke test, verificar que carga y no falla de forma crítica.
¿Cómo se ve en un caso concreto?
Ejemplo con una app bancaria y tiempo limitado [04:15]:
- Login recién modificado, lo usa todo el mundo, si falla nadie entra. Puntaje: nueve. Acción: regresión completa.
- Historial de transacciones sin cambios recientes, pero confunde usuarios si falla. Puntaje: intermedio. Acción: pruebas funcionales.
- Página de configuración de idioma, estable, casi sin uso, falla cosmética. Puntaje: uno. Acción: smoke test.
¿Qué hacer cuando el tiempo no alcanza?
Documenta qué probaste, qué omitiste y por qué. Los stakeholders deben aceptar el riesgo residual por escrito. Eso convierte pruebas apresuradas en una decisión defendible, no en una apuesta silenciosa [04:52].
Una trampa final: verifica que realmente usaste los dos factores. ¿Hay una lista escrita con rating de probabilidad y de impacto por separado? ¿El orden de ejecución coincide con esos ratings? Si un área de riesgo bajo se probó antes que una de riesgo alto sin justificación, el instinto tomó el control [05:15]. Es como un médico recetando sin diagnóstico escrito: no puedes confirmar que la decisión fue basada en evidencia.
¿Ya aplicaste esta fórmula en tu proyecto? Elige tres funcionalidades, asígnales probabilidad e impacto por separado, y comparte si el orden resultante te sorprendió frente a lo que tu instinto indicaba.
