Odpowiedź.

Historia pytania:

Testowanie odzyskiwania po awariach (recovery testing) jest krytycznie ważne dla systemów, w których istotne są zarówno integralność danych, jak i odporność działania. Historycznie ten rodzaj testowania był stosowany głównie w systemach bankowych, finansowych i medycznych, gdzie utrata informacji jest niedopuszczalna.

Problem:

Głównym wyzwaniem jest ręczne modelowanie sytuacji awarii i późniejsza weryfikacja poprawności odzyskiwania danych, procesów lub stanów. Ręczne podejście wiąże się z błędami testera podczas odtwarzania scenariuszy, niedocenianiem rzadkich sytuacji i brakiem zautomatyzowanych narzędzi kontrolnych.

Rozwiązanie:

Optymalne ręczne testowanie recovery buduje się według scenariusza:

1. Określenie krytycznych danych i operacji do odzyskania
2. Modelowanie awarii: odmontowanie dysku, odłączenie sieci, awaryjne wyłączenie
3. Ocena reakcji systemu: czy integralność danych została zachowana, czy możliwe jest poprawne działanie po odzyskaniu
4. Sprawdzenie work-flow: aplikacja powinna albo poprawnie się odtworzyć, albo dać zrozumiały błąd i narzędzia do ręcznego odzyskiwania

Kluczowe cechy:

Konieczność głębokiego zrozumienia krytycznych danych biznesowych
Odtworzenie "zepsutego" środowiska
Skrupulatne porównanie inwariantów przed i po awarii

Pytania z haczykiem.

Czy wystarczy sprawdzić odzyskiwanie tylko po jednym typie awarii (np. wyłączenie zasilania)?

Nie, należy modelować różne awarie — problemy z siecią, bazą danych, awarie sprzętowe itp. Tylko kompleksowe testowanie da przekonujący wynik.

Czy można uznać odzyskiwanie za udane, jeśli aplikacja po prostu uruchomiła się bez błędów?

Nie, ważne jest, aby upewnić się, że wszystkie informacje i procesy zostały całkowicie odzyskane — w przeciwnym razie możliwa jest "cicha" utrata danych, która nie zostanie wykryta.

Czy należy wykonać kopię zapasową danych przed recovery testing?

Obowiązkowo! Przed każdym sabotażem należy wykonać "punkt kontrolny" wszystkich krytycznych danych. Umożliwi to porównanie ich przed i po awariach.

Typowe błędy i anty-patterny

Testowanie tylko jednego konkretnego przypadku awarii
Pominięcie weryfikacji całej logiki biznesowej po restarcie
Praca bez zabezpieczenia (backup) danych źródłowych

Przykład z życia

Negatywny przypadek

Tester zasymulował tylko wyłączenie zasilania, nie sprawdzając utraty połączenia z bazą danych. W rezultacie po awarii część transakcji "zaginęła".

Plusy:

Szybkie i proste przeprowadzenie testu

Minusy:

Utracono krytyczne dane w rzeczywistej eksploatacji

Pozytywny przypadek

Tester zaplanował różne typy awarii, wykonał kopie zapasowe, przeprowadził ręczne porównanie i wykrył kilka błędów związanych z niepoprawnym odzyskiwaniem. Wszystkie krytyczne procesy zostały zachowane.