Risposta.

Storia della domanda:

Il testing di recupero dopo guasti (recovery testing) è criticamente importante per i sistemi in cui sono significativi sia l'integrità dei dati che l'affidabilità operativa. Storicamente, questo tipo di testing è stato applicato principalmente a sistemi bancari, finanziari e sanitari, dove la perdita di informazioni è inaccettabile.

Problema:

La sfida principale è modellare manualmente situazioni di guasto e successivamente verificare la correttezza del recupero dei dati, dei processi o degli stati. L'approccio manuale incorpora errori del tester nella riproduzione degli scenari, sottovalutazione di situazioni rare e assenza di strumenti di controllo automatizzati.

Soluzione:

Il testing manuale di recovery ottimale si costruisce seguendo questo scenario:

1. Identificazione dei dati critici e delle operazioni per il recupero
2. Modellazione del guasto: smontaggio del disco, disconnessione della rete, spegnimento di emergenza
3. Valutazione della reazione del sistema: è stata mantenuta l'integrità dei dati? È possibile un corretto funzionamento dopo il recupero?
4. Verifica del work-flow: l'applicazione deve O ripristinarsi correttamente da sola O fornire un errore chiaro e strumenti per il recupero manuale

Caratteristiche chiave:

Necessità di una profonda comprensione dei dati aziendali critici
Ricreazione di un ambiente "rotto"
Verifica scrupolosa degli invarianti prima e dopo il guasto

Domande insidiose.

È sufficiente testare il recupero solo dopo un tipo di guasto (ad esempio, interruzione di corrente)?

No, è necessario modellare diversi guasti: problemi di rete, di database, guasti hardware, ecc. Solo un testing complessivo darà un risultato convincente.

Si può considerare il recupero riuscito se l'applicazione si avvia semplicemente senza errori?

No, è importante assicurarsi che tutte le informazioni e tutti i processi siano stati completamente recuperati; altrimenti è possibile una "silenziosa" perdita di dati che non verrà rilevata.

È necessario fare un backup dei dati prima del recovery testing?

Assolutamente! Prima di ogni sabotaggio, è necessario fare un "punto di controllo" di tutti i dati critici. Questo consentirà di confrontarli prima e dopo i guasti.

Errori comuni e anti-pattern

Testare solo un singolo caso specifico di guasto
Omettere la verifica dell'intera logica aziendale dopo un riavvio
Lavorare senza riserva (backup) dei dati di partenza

Esempi della vita reale

Caso negativo

Il tester ha modellato solo l'interruzione di corrente, senza verificare la perdita di connessione con il database. Di conseguenza, dopo il guasto, parte delle transazioni è andata "persa".

Pro:

Test veloce e semplice da eseguire

Contro:

Perdita di dati critici in un'operazione reale

Caso positivo

Il tester ha pianificato diversi tipi di guasti, ha effettuato backup, ha condotto una verifica manuale e ha evidenziato diversi bug con recuperi non corretti. Tutti i processi critici sono stati mantenuti.