Réponse.

Contexte de la question :

Les tests de récupération après des pannes (recovery testing) sont cruciaux pour les systèmes où à la fois l'intégrité des données et la résilience opérationnelle sont significatives. Historiquement, ce type de test a été principalement appliqué aux systèmes bancaires, financiers et médicaux, où la perte d'informations est inacceptable.

Problème :

Le principal défi est de modéliser manuellement des situations de panne et de vérifier ensuite la validité de la récupération des données, des processus ou des états. L'approche manuelle peut introduire des erreurs de la part du testeur lors de la reproduction des scénarios, une sous-estimation des situations rares et un manque d'outils de contrôle automatisés.

Solution :

Un testing de récupération manuel optimal se construit selon le scénario suivant :

1. Identification des données critiques et des opérations pour la récupération
2. Modélisation de la panne : démontage du disque, déconnexion du réseau, coupure d'urgence
3. Évaluation de la réponse du système : l'intégrité des données a-t-elle été préservée, le fonctionnement est-il correct après la récupération
4. Vérification du work-flow : l'application doit soit se rétablir correctement d'elle-même, soit fournir une erreur claire et des outils pour une récupération manuelle

Caractéristiques clés :

Nécessité d'une compréhension approfondie des données critiques pour l'entreprise
Recréation d'un environnement "cassé"
Vérification minutieuse des invariants avant et après la panne

Questions pièges.

Est-il suffisant de tester la récupération après un seul type de panne (par exemple, une perte de courant) ?

Non, il faut modéliser différents types de pannes — problèmes de réseau, de base de données, pannes matérielles, etc. Seuls des tests complets fourniront un résultat convaincant.

Peut-on considérer la récupération comme réussie si l'application se lance simplement sans erreurs ?

Non, il est important de s'assurer que toutes les informations et tous les processus sont entièrement récupérés — sinon, une perte de données "silencieuse" peut se produire et ne sera pas détectée.

Faut-il faire une sauvegarde des données avant les tests de récupération ?

Absolument ! Avant chaque sabotage, il est nécessaire de créer un "point de contrôle" de toutes les données critiques. Cela permettra de les comparer avant et après les pannes.

Erreurs typiques et anti-modèles

Tester uniquement un cas particulier de panne
Omettre la vérification de toute la logique métier après le redémarrage
Travailler sans sauvegarder les données source

Exemple de la vie réelle

Cas négatif

Le testeur a uniquement modélisé la coupure d'alimentation, sans vérifier la perte de connexion avec la base de données. En conséquence, après la panne, une partie des transactions a été "perdue".

Avantages :

Test facile et rapide à réaliser

Inconvénients :

Des pertes de données critiques en exploitation réelle ont été négligées

Cas positif

Le testeur a planifié différents types de pannes, effectué des sauvegardes, réalisé une vérification manuelle et a découvert plusieurs bugs liés à une récupération incorrecte. Tous les processus critiques ont été préservés.