¿Por Qué Testing Basado en Riesgos?
Ningún proyecto tiene tiempo y recursos ilimitados. No puedes probar todo por igual. El testing basado en riesgos responde: ¿Dónde debemos enfocar nuestro esfuerzo?
La respuesta: enfócate en áreas de mayor riesgo — donde los defectos son más probables Y donde su impacto sería más severo.
Entendiendo el Riesgo
Riesgo = Probabilidad × Impacto
- Probabilidad: ¿Qué tan probable es que exista un defecto?
- Impacto: Si existe, ¿qué tan severas son las consecuencias?
Factores de Probabilidad
| Factor | Mayor Probabilidad |
|---|---|
| Complejidad de código | Algoritmos complejos, muchas condiciones |
| Nueva tecnología | Primera vez usando un framework o API |
| Experiencia del desarrollador | Desarrollador junior o nuevo |
| Frecuencia de cambios | Código modificado frecuentemente |
| Puntos de integración | Múltiples sistemas interactuando |
| Deadlines ajustados | Código escrito bajo presión |
| Historial | Área con muchos defectos previos |
Factores de Impacto
| Factor | Mayor Impacto |
|---|---|
| Transacciones financieras | Pérdida de dinero, cargos incorrectos |
| Seguridad/privacidad | Brecha de datos, acceso no autorizado |
| Seguridad crítica | Daño físico a usuarios |
| Flujo de usuario principal | Login, checkout, features primarios |
| Regulatorio | Violaciones de compliance, multas |
| Reputación | Fallas públicas |
| Integridad de datos | Pérdida o corrupción permanente |
Riesgo de Producto vs Riesgo de Proyecto
Riesgos de Producto
Problemas potenciales de calidad en el software:
| Riesgo | Probabilidad | Impacto | Nivel |
|---|---|---|---|
| Error en procesamiento de pagos | Media | Crítico | Alto |
| Búsqueda retorna resultados incorrectos | Baja | Alto | Medio |
| CSS roto en móvil | Media | Medio | Medio |
| Typo en página de ayuda | Baja | Bajo | Bajo |
Riesgos de Proyecto
Amenazan el proceso de testing:
| Riesgo | Probabilidad | Impacto | Mitigación |
|---|---|---|---|
| Entorno no disponible | Alta | Alto | Backup con Docker |
| Requisitos cambian mid-sprint | Media | Alto | Proceso de control de cambios |
| QA enfermo | Baja | Alto | Cross-training |
| API de terceros caída | Media | Medio | Servicios mock |
La Matriz de Riesgos
ALTO Impacto
Crítico] HL[ALTA Probabilidad
BAJO Impacto
Medio] LH[BAJA Probabilidad
ALTO Impacto
Alto] LL[BAJA Probabilidad
BAJO Impacto
Bajo] end style HH fill:#F44336,color:#fff style HL fill:#FFC107,color:#000 style LH fill:#FF9800,color:#fff style LL fill:#4CAF50,color:#fff
Cómo Usar la Matriz
| Nivel | Enfoque de Testing |
|---|---|
| Crítico | Extensivo: todas las técnicas, automatización, exploratorio, seguridad, rendimiento |
| Alto | Exhaustivo: cobertura completa, automatización para regresión |
| Medio | Estándar: casos funcionales, testing negativo básico |
| Bajo | Mínimo: smoke tests, validación básica |
El Proceso de Testing Basado en Riesgos
de Riesgos] --> RA[2. Análisis
de Riesgos] RA --> RP[3. Priorización
Basada en Riesgo] RP --> TE[4. Ejecución
de Tests] TE --> RM[5. Monitoreo
de Riesgos] RM --> RI style RI fill:#4CAF50,color:#fff style RA fill:#2196F3,color:#fff style RP fill:#FF9800,color:#fff style TE fill:#9C27B0,color:#fff style RM fill:#F44336,color:#fff
Paso 1: Identificación
Participantes: QA, desarrolladores, product owners, arquitectos, operaciones.
Técnicas: Brainstorming, revisión de datos históricos de defectos, análisis de requisitos, revisión de arquitectura.
Paso 2: Análisis
Para cada riesgo: Probabilidad (1-5) × Impacto (1-5) = Score de Riesgo.
Paso 3: Priorización
| Prioridad | % de Esfuerzo | Profundidad |
|---|---|---|
| Crítico (15-25) | 40% | Todas las técnicas |
| Alto (10-14) | 30% | Funcional + negativo + boundary |
| Medio (5-9) | 20% | Funcional + negativo clave |
| Bajo (1-4) | 10% | Smoke tests |
Paso 4: Ejecución
Ejecutar tests en orden de prioridad. Si se acaba el tiempo, las áreas de mayor riesgo ya están probadas.
Paso 5: Monitoreo
Los riesgos cambian durante el testing. Actualizar el registro continuamente.
Ejercicio: Crear un Registro de Riesgos y Priorizar Test Cases
Eres QA lead de un portal de salud en línea donde los pacientes pueden:
- Registrarse y gestionar su perfil (incluyendo historial médico)
- Agendar citas con doctores
- Ver resultados de exámenes y registros médicos
- Comunicarse con doctores por mensajería segura
- Pagar consultas en línea
- Recibir notificaciones de prescripciones
Contexto regulatorio: El sistema debe cumplir con HIPAA para privacidad de datos de pacientes.
Tu tarea:
- Crear un registro de riesgos con al menos 10 riesgos
- Puntuar cada riesgo (Probabilidad 1-5, Impacto 1-5)
- Categorizar en la matriz de riesgos
- Listar los 5 test cases que ejecutarías primero
- Explicar cómo ajustarías si el cronograma se reduce 30%
Pista
Violaciones HIPAA pueden costar $100-$50,000 por violación. Datos médicos son la categoría más sensible. Errores en citas pueden resultar en cuidado crítico perdido. Notificaciones de prescripciones deben ser oportunas y precisas.
Solución de Ejemplo
Registro de Riesgos
| ID | Riesgo | Tipo | P | I | Score | Prioridad |
|---|---|---|---|---|---|---|
| R1 | Registros médicos visibles a usuarios no autorizados | Producto | 2 | 5 | 10 | Crítico |
| R2 | Notificación de prescripción enviada a paciente equivocado | Producto | 2 | 5 | 10 | Crítico |
| R3 | Mensajería segura no encriptada | Producto | 3 | 5 | 15 | Crítico |
| R4 | Doble cobro al paciente | Producto | 3 | 4 | 12 | Alto |
| R5 | Citas permiten slots superpuestos | Producto | 4 | 3 | 12 | Alto |
| R6 | Resultados de exámenes muestran valores incorrectos | Producto | 2 | 5 | 10 | Crítico |
| R7 | Timeout de sesión muy largo (HIPAA requiere corto) | Producto | 3 | 4 | 12 | Alto |
| R8 | Entorno de prueba sin enmascaramiento de datos | Proyecto | 4 | 4 | 16 | Crítico |
| R9 | Integración con sistema EHR del hospital falla | Proyecto | 3 | 4 | 12 | Alto |
| R10 | Equipo QA no familiarizado con HIPAA | Proyecto | 3 | 3 | 9 | Medio |
Top 5 Test Cases
- Control de acceso: Paciente A no puede ver registros de Paciente B (R1)
- Encriptación de mensajería: Mensajes encriptados en tránsito y reposo (R3)
- Precisión de notificación de prescripción: Notificación corresponde al paciente y prescripción correctos (R2)
- Precisión de resultados: Valores de laboratorio correctos con unidades y rangos (R6)
- Timeout de sesión HIPAA: Sesión expira después del período requerido (R7)
Ajuste con 30% Menos de Tiempo
Mantener esfuerzo completo (Críticos): R1, R2, R3, R6 — no negociables para HIPAA.
Reducir esfuerzo (Altos): R4, R5, R7, R9 — solo happy path y casos negativos clave.
Diferir (Medio/Bajo): R10 — abordar con documentación. Testing cosmético diferido completamente.
Comunicar: “Con 30% menos de tiempo, mantenemos cobertura completa para áreas críticas HIPAA. Reducimos cobertura para pagos y agendamiento, aceptando mayor riesgo. Recomendamos un sprint post-release enfocado.”
Testing Basado en Riesgos en Agile
- Sprint Planning: Identificar riesgos para los user stories del sprint
- Daily Standup: Reportar descubrimientos de riesgo
- Sprint Review: Actualizar registro de riesgos
- Retrospective: Evaluar si la evaluación de riesgos fue precisa
Consejos Pro
Involucra a todo el equipo en identificación de riesgos. Desarrolladores saben dónde el código es frágil. POs saben qué es crítico para el negocio. Ops sabe qué ha fallado antes.
Actualiza el registro continuamente. El riesgo no es estático. Un área de alto riesgo puede volverse bajo riesgo después de testing exhaustivo.
Usa datos de defectos para calibrar. Si un área consistentemente tiene más defectos, aumenta su score de probabilidad.
Documenta tus decisiones. Cuando reduces testing en un área de bajo riesgo, documéntalo. Si un defecto escapa, puedes explicar la lógica.
No se trata de probar menos. Se trata de probar más inteligentemente. Mismo esfuerzo, mejor enfocado.