¿Qué Son las Pruebas de Confiabilidad?
Las pruebas de confiabilidad (reliability testing) evalúan si un sistema realiza su función prevista de manera consistente durante un período específico bajo condiciones definidas. Un sistema no es verdaderamente confiable solo porque pase pruebas funcionales — debe continuar funcionando correctamente con el tiempo, bajo uso sostenido y a través de condiciones variables.
Considera una aplicación de banca en línea. Puede pasar todas las pruebas funcionales durante una sesión de 30 minutos. Pero, ¿qué sucede cuando miles de usuarios interactúan con ella continuamente durante 72 horas? Las pruebas de confiabilidad responden esa pregunta.
Métricas Clave de Confiabilidad
Dos métricas son fundamentales en las pruebas de confiabilidad:
MTBF (Mean Time Between Failures — Tiempo Medio Entre Fallas) mide el tiempo promedio que un sistema opera antes de que ocurra una falla. Por ejemplo, si un servidor experimenta 3 fallas en 300 horas de operación, el MTBF es 100 horas. Un MTBF más alto indica mayor confiabilidad.
MTTR (Mean Time To Repair/Recover — Tiempo Medio de Reparación/Recuperación) mide el tiempo promedio requerido para restaurar un sistema a estado operacional después de una falla. Si esas 3 fallas tomaron 2, 4 y 3 horas en arreglar respectivamente, el MTTR es 3 horas. Un MTTR más bajo indica mejor capacidad de recuperación.
Disponibilidad combina ambas métricas: Disponibilidad = MTBF / (MTBF + MTTR). Usando el ejemplo anterior: 100 / (100 + 3) = 97.1%. Este es el porcentaje de tiempo que el sistema está operacional.
| Métrica | Fórmula | Objetivo | Ejemplo |
|---|---|---|---|
| MTBF | Tiempo total activo / Número de fallas | Maximizar | 100 horas |
| MTTR | Tiempo total de reparación / Número de fallas | Minimizar | 3 horas |
| Disponibilidad | MTBF / (MTBF + MTTR) | Maximizar | 97.1% |
Tipos de Pruebas de Confiabilidad
Pruebas de resistencia (endurance testing) ejecutan el sistema bajo carga esperada durante un período extendido (24-72 horas) para detectar fugas de memoria, agotamiento de recursos y patrones de degradación.
Pruebas de estrés-confiabilidad combinan pruebas de estrés con medición de confiabilidad — ¿cómo cambia la tasa de fallas cuando el sistema opera al 80-90% de capacidad durante un tiempo prolongado?
Pruebas de perfil operacional simulan la distribución real de operaciones de usuarios. Si el 60% de los usuarios navega, el 30% agrega al carrito y el 10% finaliza la compra, la prueba refleja estas proporciones.
¿Qué Son las Pruebas de Recuperación?
Las pruebas de recuperación (recovery testing) verifican que un sistema puede restaurarse — o ser restaurado — a un estado funcional después de experimentar una falla. Mientras las pruebas de confiabilidad se centran en prevenir y medir fallas, las pruebas de recuperación se centran en lo que sucede después de que ocurre una falla.
Todo sistema eventualmente fallará. La pregunta no es si fallará, sino qué tan elegantemente.
Escenarios Comunes de Falla
Crash de la aplicación. El proceso del servidor termina inesperadamente. ¿Puede la aplicación reiniciarse automáticamente? ¿Se preservan las transacciones en curso o se revierten correctamente?
Corte de energía. El servidor pierde energía. Cuando regresa la energía, ¿el sistema se levanta? ¿Los datos están intactos? ¿Retoma desde donde quedó?
Caída de red. La conectividad entre servicios se interrumpe. ¿Los servicios reintentan? ¿Se degradan elegantemente? ¿Qué sucede con los datos en tránsito?
Corrupción de base de datos. Un sector de disco falla o una operación de escritura se interrumpe. ¿Puede la base de datos recuperarse desde su log de transacciones? ¿Son consistentes los datos?
Falla de hardware. Un componente físico (disco, memoria, tarjeta de red) falla. ¿El sistema lo detecta y responde apropiadamente?
Pruebas de Failover
Las pruebas de failover verifican que cuando un componente principal falla, el tráfico o procesamiento cambia automáticamente a un componente en espera (redundante). Esto es crítico para sistemas de alta disponibilidad.
Failover activo-pasivo: Un servidor en espera aguarda inactivo hasta que el principal falla. La prueba verifica que el respaldo toma el control dentro del RTO (Recovery Time Objective) definido.
Failover activo-activo: Múltiples servidores comparten la carga. Cuando uno falla, los otros absorben su tráfico. La prueba verifica que no se pierden solicitudes y el rendimiento se mantiene aceptable.
Qué medir durante las pruebas de failover:
- Tiempo de failover — ¿Cuánto tarda el respaldo en tomar el control?
- Pérdida de datos — ¿Se perdieron transacciones durante el cambio?
- Impacto al usuario — ¿Los usuarios experimentaron errores o la transición fue transparente?
- Failback — Cuando el principal se recupera, ¿el tráfico regresa correctamente?
Pruebas de Backup y Restauración
Tener backups no es suficiente — debes probarlos. Un backup no probado no es un backup; es una esperanza.
Las pruebas de backup y restauración verifican:
- Los backups se completan exitosamente dentro de la ventana de respaldo
- Los datos del backup no están corruptos (verificaciones de integridad)
- La restauración funciona en el ambiente objetivo
- La restauración se completa dentro del RTO
- Los datos restaurados son completos y cumplen con el RPO
| Término | Definición | Ejemplo |
|---|---|---|
| RTO (Recovery Time Objective) | Tiempo máximo aceptable de inactividad | 4 horas |
| RPO (Recovery Point Objective) | Pérdida máxima aceptable de datos (tiempo) | 1 hora |
Si tu RPO es 1 hora, debes hacer backup al menos cada hora. Si tu RTO es 4 horas, debes poder restaurar desde el backup en 4 horas.
Pruebas de Recuperación ante Desastres
Las pruebas de Disaster Recovery (DR) van más allá de fallas de componentes individuales para simular escenarios catastróficos: caídas de data centers completos, fallas regionales o fallas simultáneas de múltiples componentes.
Las pruebas DR típicamente se realizan trimestral o anualmente e incluyen:
- Activar el plan DR con roles y procedimientos definidos
- Cambiar las operaciones al sitio DR
- Ejecutar operaciones críticas desde el sitio DR
- Medir cumplimiento de RTO y RPO
- Regresar al sitio principal
Tipos de pruebas DR (de menos a más disruptivas):
- Ejercicio de mesa (tabletop) — Revisar el plan DR verbalmente sin tomar acción
- Simulación — Simular un escenario de desastre sin apagar sistemas
- Prueba paralela — Levantar el sitio DR mientras el principal sigue funcionando
- Prueba de interrupción completa — Apagar el sitio principal y operar desde DR
Ejercicio: Diseña Escenarios de Pruebas de Confiabilidad
Eres el QA lead de un sistema crítico de agendamiento de citas médicas. El sistema tiene estas características:
- Aplicación web que atiende 50,000 usuarios diarios
- Base de datos PostgreSQL con registros de pacientes
- Integración con APIs externas de verificación de seguros
- Configuración de failover activo-pasivo con dos servidores
- Disponibilidad objetivo: 99.9% (8.76 horas máximo de inactividad por año)
- RTO: 30 minutos, RPO: 5 minutos
Diseña escenarios de prueba cubriendo:
Parte 1: Métricas de confiabilidad. Basado en el objetivo de 99.9% de disponibilidad, calcula el MTTR máximo aceptable si el sistema experimenta una falla por mes (MTBF = 720 horas). ¿Cumple con los requisitos?
Parte 2: Escenarios de recuperación. Escribe 5 escenarios de prueba de recuperación para los siguientes tipos de falla:
- Crash del servidor de aplicaciones
- Agotamiento del pool de conexiones de base de datos
- API externa de seguros inaccesible
- Falla de hardware del servidor principal (prueba de failover)
- Backup de base de datos corrupto
Para cada escenario, especifica: el disparador, comportamiento esperado, tiempo de recuperación aceptable y pasos de verificación de integridad de datos.
Parte 3: Plan de prueba DR. Diseña un plan de prueba de disaster recovery que verifique que el sistema puede cumplir sus objetivos de RTO y RPO. Incluye el tipo de prueba, prerrequisitos, pasos de ejecución y criterios de éxito.
Pista
Para la Parte 1, usa la fórmula de disponibilidad: Disponibilidad = MTBF / (MTBF + MTTR). Resuelve para MTTR con Disponibilidad = 0.999 y MTBF = 720. Luego compara el MTTR calculado contra el RTO de 30 minutos.Para la Parte 2, piensa en qué debe hacer el sistema automáticamente versus qué requiere intervención manual. Los sistemas de salud tienen requisitos estrictos de integridad de datos — no se deben perder datos de pacientes.
Solución
Parte 1: Métricas de Confiabilidad
Dado: Disponibilidad = 99.9%, MTBF = 720 horas
0.999 = 720 / (720 + MTTR)
720 + MTTR = 720 / 0.999
720 + MTTR = 720.72
MTTR = 0.72 horas = 43.2 minutos
El MTTR calculado (43.2 minutos) excede el RTO (30 minutos). Esto significa que el objetivo de disponibilidad o el RTO necesitan ajustarse, o el sistema necesita mejores mecanismos de auto-recuperación para reducir el MTTR por debajo de 30 minutos.
Parte 2: Escenarios de Recuperación
Escenario 1: Crash del servidor de aplicaciones
- Disparador: Terminar el proceso con
kill -9 - Comportamiento esperado: El monitor de procesos detecta el crash en 30 segundos, reinicia la aplicación automáticamente. Las solicitudes en curso reciben un error que permite reintento. Sin pérdida de datos.
- Tiempo de recuperación aceptable: Menos de 2 minutos
- Verificación: Confirmar que todas las transacciones se completaron o revirtieron. Verificar que no hay registros de citas huérfanos.
Escenario 2: Agotamiento del pool de conexiones
- Disparador: Simular 500 conexiones concurrentes excediendo el límite del pool de 100
- Comportamiento esperado: La aplicación retorna “servicio temporalmente no disponible” para nuevas solicitudes. Las conexiones existentes se completan normalmente.
- Tiempo de recuperación aceptable: Menos de 5 minutos después de reducir la carga
- Verificación: Consultar la base de datos por transacciones incompletas. Verificar que las métricas del pool vuelvan a niveles normales.
Escenario 3: API externa de seguros inaccesible
- Disparador: Bloquear acceso de red al endpoint de la API de seguros
- Comportamiento esperado: La aplicación usa patrón circuit breaker — después de 3 intentos fallidos, deja de llamar la API y muestra un mensaje amigable. Las citas pueden agendarse sin verificación de seguro (encoladas para verificación posterior).
- Tiempo de recuperación aceptable: Circuit breaker se abre en 30 segundos. Recuperación completa en 1 minuto después de que la API regresa.
- Verificación: Verificar que las verificaciones encoladas se procesan cuando la API regresa.
Escenario 4: Falla de hardware del servidor principal
- Disparador: Apagar el servidor principal
- Comportamiento esperado: Se activa el failover activo-pasivo. El servidor en espera toma el control dentro del RTO.
- Tiempo de recuperación aceptable: Menos de 5 minutos
- Verificación: Confirmar que el respaldo tiene los datos más recientes (dentro del RPO de 5 minutos). Probar flujos completos en el respaldo.
Escenario 5: Backup de base de datos corrupto
- Disparador: Corromper intencionalmente un archivo de backup e intentar restauración
- Comportamiento esperado: El proceso de restauración detecta la corrupción mediante verificación de checksum. El sistema recurre al backup anterior conocido como bueno. Se genera una alerta.
- Tiempo de recuperación aceptable: Detección en 5 minutos. Total menos de 30 minutos.
- Verificación: Comparar conteos de registros y checksums entre datos restaurados y la fuente.
Parte 3: Plan de Prueba DR
Tipo de prueba: Prueba paralela
Prerrequisitos:
- Sitio DR configurado con infraestructura idéntica
- Lag de replicación de base de datos menor a 5 minutos
- Runbook actual disponible para todos los participantes
- Dashboards de monitoreo configurados para el sitio DR
Pasos de ejecución:
- Anunciar la prueba DR a todos los stakeholders
- Verificar que la base de datos del sitio DR está sincronizada
- Redirigir 10% del tráfico al sitio DR
- Monitorear rendimiento del sitio DR por 30 minutos
- Simular falla del sitio principal redirigiendo todo el tráfico al sitio DR
- Medir tiempo desde la redirección hasta estado operacional completo
- Ejecutar pruebas de flujos críticos
- Operar desde el sitio DR por 2 horas
- Redirigir tráfico de vuelta al sitio principal
- Verificar consistencia de datos entre ambas bases de datos
Criterios de éxito:
- Cambio completo en menos de 30 minutos (RTO)
- Pérdida de datos menor a 5 minutos de transacciones (RPO)
- Todos los flujos críticos se ejecutan exitosamente en el sitio DR
- Degradación de rendimiento menor al 20%
- Regreso al sitio principal sin pérdida de datos
Pruebas de Confiabilidad en CI/CD
Los equipos modernos integran pruebas de confiabilidad en su pipeline de entrega:
Ingeniería del caos (enfoque Chaos Monkey de Netflix) inyecta fallas intencionalmente en ambientes de producción o pre-producción para probar mecanismos de recuperación continuamente. Herramientas como Chaos Monkey, Gremlin y Litmus ayudan a automatizar la inyección de fallas.
Deployments canary sirven código nuevo a un pequeño porcentaje de usuarios, monitoreando por degradación de confiabilidad antes del despliegue completo.
Health checks y readiness probes (probes de liveness/readiness de Kubernetes) proporcionan monitoreo continuo de confiabilidad y recuperación automática a nivel de infraestructura.
Puntos Clave
- Las pruebas de confiabilidad miden qué tan consistentemente funciona un sistema usando métricas MTBF, MTTR y disponibilidad
- Las pruebas de recuperación verifican que el sistema puede volver a un estado funcional después de crashes, cortes de energía, fallas de red y hardware
- Las pruebas de failover aseguran que los sistemas en espera toman el control automáticamente dentro de tiempos aceptables
- Las pruebas de backup/restore deben realizarse regularmente — un backup no probado no es un backup
- Las pruebas de disaster recovery van desde ejercicios de mesa hasta pruebas de interrupción completa
- RTO define el tiempo máximo aceptable de inactividad; RPO define la pérdida máxima aceptable de datos
- La ingeniería del caos lleva las pruebas de confiabilidad al pipeline CI/CD como práctica continua