Respuesta.

Historia de la pregunta:

Las pruebas de recuperación después de fallos (recovery testing) son críticamente importantes para sistemas donde la integridad de los datos y la resiliencia operativa son significativas. Históricamente, este tipo de prueba se ha utilizado principalmente en sistemas bancarios, financieros y médicos, donde la pérdida de información es inaceptable.

Problema:

El principal desafío es modelar manualmente situaciones de fallo y la posterior verificación de la corrección de la recuperación de datos, procesos o estados. El enfoque manual puede introducir errores del probador al reproducir escenarios, subestimar situaciones raras y carecer de herramientas automatizadas de control.

Solución:

Las pruebas manuales óptimas de recovery testing se construyen según el siguiente escenario:

1. Identificación de datos críticos y operaciones para la recuperación
2. Modelado de fallos: desmontar el disco, desconectar la red, apagado de emergencia
3. Evaluación de la respuesta del sistema: se mantuvo la integridad de los datos, ¿es posible un funcionamiento correcto tras la recuperación?
4. Verificación del flujo de trabajo: la aplicación debe autocomponerse correctamente o proporcionar un error claro y herramientas para la recuperación manual

Características clave:

Necesidad de un profundo entendimiento de los datos críticos para el negocio
Recreación de un entorno "roto"
Comparación meticulosa de invariantes antes y después de la falla

Preguntas con trampa.

¿Es suficiente comprobar la recuperación solo después de un tipo de fallo (por ejemplo, un corte de energía)?

No, se deben modelar diferentes fallos: problemas de red, fallos de base de datos, fallos de hardware, etc. Solo una prueba integral dará resultados convincentes.

¿Se puede considerar exitoso un proceso de recuperación si la aplicación simplemente se inicia sin errores?

No, es importante asegurarse de que toda la información y todos los procesos se hayan recuperado por completo; de lo contrario, la pérdida "silenciosa" de datos puede ocurrir y no se detectará.

¿Es necesario hacer backup de datos antes de la recuperación testing?

¡Es obligatorio! Antes de cada sabotaje, se debe crear un "punto de control" de todos los datos críticos. Esto permitirá compararlos antes y después de los fallos.

Errores típicos y anti-patrones

Probar solo un caso privado de fallo
Omitir la verificación de toda la lógica de negocio después del reinicio
Trabajar sin respaldo (backup) de los datos originales

Ejemplo de la vida real

Caso negativo

El probador simuló solo un corte de energía, sin verificar la pérdida de conexión con la base de datos. Como resultado, después del fallo, parte de las transacciones "se perdió".

Ventajas:

Rápido y fácil de realizar la prueba

Desventajas:

Se pasaron por alto pérdidas críticas de datos en explotación real

Caso positivo

El probador planificó diferentes tipos de fallos, hizo copias de seguridad, realizó una verificación manual y levantó varios bugs con recuperación incorrecta. Todos los procesos críticos se mantuvieron.