Che cos’è, funzionamento e importanza del test di migrazione dei dati

Oggigiorno, si sente spesso dire che un’applicazione viene spostata su un server diverso, la tecnologia viene modificata, viene aggiornata alla versione successiva o spostata su un server di database diverso ecc.,

• Cosa significa questo in realtà?
• Cosa ci si aspetta dal team di test in queste situazioni?

Dal punto di vista del test, tutto ciò significa che l’applicazione deve essere testata completamente end-to-end insieme alla migrazione dal sistema esistente al nuovo sistema con successo. 

Il test del sistema deve essere eseguito in questo caso con tutti i dati, che vengono utilizzati in una vecchia applicazione e anche con i nuovi dati. La funzionalità esistente deve essere verificata insieme alla funzionalità nuova/modificata.

In altre parole, invece del semplice test di migrazione, può anche essere definito test di migrazione dei dati, in cui tutti i dati dell’utente verranno migrati su un nuovo sistema.

Pertanto, il test di migrazione include il test con vecchi dati, nuovi dati o una combinazione di entrambe le vecchie funzionalità (funzionalità invariate) e le nuove funzionalità.

La vecchia applicazione è generalmente definita come applicazione “legale “. Insieme alle applicazioni nuove/aggiornate, è anche obbligatorio continuare a testare le applicazioni legacy finché quelle nuove/aggiornate non diventano stabili e coerenti. L’ampio test di migrazione sulla nuova applicazione rivelerà i nuovi problemi che non sono stati trovati nell’applicazione legacy.

Che cos’è il test di migrazione?

Il test di migrazione (in inglese Data Migration Testing) è un processo di verifica della migrazione del sistema legacy al nuovo sistema con interruzioni/tempo di inattività minimi, con integrità dei dati e nessuna perdita di dati, garantendo nel contempo che tutti gli aspetti funzionali e non funzionali specificati dell’applicazione siano soddisfatti post-migrazione.

Perché il test di migrazione?

Come sappiamo, la migrazione dell’applicazione a un nuovo sistema potrebbe essere dovuta a vari motivi, consolidamento del sistema, tecnologia obsoleta, ottimizzazione o qualsiasi altro motivo.

Pertanto, mentre il sistema in uso deve essere migrato a un nuovo sistema, è essenziale garantire i seguenti punti:

1. Qualsiasi tipo di interruzione/inconveniente causato all’utente a causa della migrazione deve essere evitato/ridotto al minimo. Es: tempi di inattività, perdita di dati
2. È necessario assicurarsi che l’utente possa continuare a utilizzare tutte le funzionalità del software causando danni minimi o nulli durante la migrazione. Es: modifica della funzionalità, rimozione di una particolare funzionalità
3. È anche importante anticipare ed escludere tutti i possibili glitch/ostacoli che potrebbero verificarsi durante l’effettiva migrazione del sistema live.

Pertanto, al fine di garantire una migrazione regolare del sistema live eliminando tali difetti, è essenziale eseguire i test di migrazione in laboratorio.

Questo test ha la sua importanza e gioca un ruolo vitale quando i dati entrano in scena.

Tecnicamente, è anche richiesto di essere eseguito per le seguenti finalità:

• Per garantire la compatibilità dell’applicazione nuova/aggiornata con tutti i possibili hardware e software supportati dall’applicazione legacy. Inoltre, la nuova compatibilità dovrebbe essere testata anche per il nuovo hardware e la piattaforma software.
• Per garantire che tutte le funzionalità esistenti funzionino come nell’applicazione legacy. Non dovrebbero esserci cambiamenti nel modo in cui funziona l’applicazione rispetto a quella legacy.
• La possibilità di un gran numero di difetti dovuti alla migrazione è molto alta. Molti dei difetti saranno solitamente correlati ai dati e quindi questi difetti devono essere identificati e corretti durante il test.
• Per garantire se il tempo di risposta del sistema dell’applicazione nuova/aggiornata è uguale o inferiore a quello necessario per l’applicazione precedente.
• Per garantire che la connessione tra server, hardware, software ecc. siano tutti intatti e non si interrompano durante il test. Il flusso di dati tra i diversi componenti non dovrebbe interrompersi in nessuna condizione.

Quando è necessario questo test?

I test devono essere eseguiti sia prima che dopo la migrazione.

Le diverse fasi del Test di Migrazione  da effettuare presso il Test Lab possono essere classificate come di seguito.

1. Test pre-migrazione
2. Test di migrazione
3. Test post migrazione

In aggiunta a quanto sopra, nell’ambito dell’intera attività di Migrazione vengono eseguiti anche i seguenti test .

1. Verifica della compatibilità con le versioni precedenti
2. Test di rollback

Prima di eseguire questo Test, è essenziale che qualsiasi Tester comprenda chiaramente i punti seguenti:

1. I cambiamenti che avvengono come parte del nuovo sistema (server, front end, DB, schema, flusso di dati, funzionalità ecc.,)
2. Comprendere l’effettiva strategia di migrazione definita dal team. Come avviene la migrazione, passo dopo passo le modifiche che si verificano nel back-end del sistema e gli script responsabili di queste modifiche.

Quindi è essenziale fare uno studio approfondito del vecchio e del nuovo sistema e quindi pianificare e progettare di conseguenza i casi di test e gli scenari di test da coprire come parte delle fasi di test precedenti e preparare la strategia di test.

Strategia dei test di migrazione dei dati

La progettazione della strategia di test per la migrazione include una serie di attività da svolgere e pochi aspetti da considerare. Questo serve per ridurre al minimo gli errori ei rischi che si verificano a seguito della migrazione ed eseguire il test di migrazione in modo efficace. Di seguito, le principali attività in questo test.

Formazione di squadre specializzate

Formare il team di test con i membri che hanno le conoscenze e l’esperienza richieste e fornire formazione relativa al sistema che viene migrato.

Analisi del rischio aziendale, analisi dei possibili errori

L’attività corrente non dovrebbe essere ostacolata dopo la migrazione e quindi svolgere riunioni di “Analisi dei rischi aziendali” che coinvolgono le parti interessate (Test Manager, Analista aziendale, Architetti, Proprietari di prodotto, Imprenditore ecc.) e identifica i rischi e le mitigazioni implementabili. Il test dovrebbe includere scenari per scoprire tali rischi e verificare se sono state implementate adeguate mitigazioni.

Condurre la ” Possibile analisi degli errori” utilizzando appropriati “Approcci di ipotesi di errore” e quindi progettare test attorno a questi errori per portarli alla luce durante il test.

Analisi e identificazione dell’ambito della migrazione

Analizza il chiaro ambito del test di migrazione come quando e cosa deve essere testato.

Identificare lo strumento appropriato per la migrazione

Durante la definizione della strategia di questo test, automatizzato o manuale, identificare gli strumenti che verranno utilizzati. Ad esempio: strumento automatizzato per confrontare i dati di origine e di destinazione.

Identificare l’ambiente di test appropriato per la migrazione

Identifica ambienti separati per gli ambienti pre e post migrazione per eseguire qualsiasi verifica richiesta come parte del test. Comprendere e documentare gli aspetti tecnici del Legacy e del nuovo sistema di migrazione, per garantire che l’ambiente di test sia impostato come previsto.

Documento e revisione delle specifiche del test di migrazione

Preparare il documento delle specifiche del test di migrazione che descrive chiaramente l’approccio del test, le aree di test, i metodi di test (automatici, manuali), la metodologia di test (tecniche black box e white box testing), il numero di cicli di test, il programma dei test, l’approccio alla creazione dei dati e utilizzando dati in tempo reale (le informazioni sensibili devono essere mascherate), specifiche dell’ambiente di test, qualifica dei tester ecc. ed eseguire una sessione di revisione con le parti interessate.

Lancio della produzione del sistema migrato

Analizza e documenta l’elenco delle cose da fare per la migrazione della produzione e pubblicalo con largo anticipo.

Processo e fasi della migrazione

Di seguito sono riportate le varie fasi della Migrazione.

Fase 1:  test pre-migrazione

Prima di migrare i dati, vengono eseguite serie di attività di test come parte della fase di test di pre-migrazione. Questo viene ignorato o non considerato nelle applicazioni più semplici. Ma quando devono essere migrate applicazioni complesse, le attività di pre-migrazione sono d’obbligo.

Di seguito è riportato l’elenco delle azioni intraprese durante questa fase:

• Stabilire un ambito chiaro dei dati: quali dati devono essere inclusi, quali dati devono essere esclusi, quali dati necessitano di trasformazioni/conversioni, ecc.
• Eseguire la mappatura dei dati tra legacy e la nuova applicazione – per ogni tipo di dati nell’applicazione legacy confrontare il relativo tipo nella nuova applicazione e quindi mapparli – Mappatura di livello superiore.
• Se la nuova applicazione contiene il campo che è obbligatorio, ma non è il caso in legacy, assicurati che il campo legacy non abbia quel campo come null. – Mappatura di livello inferiore.
• Studia lo schema dei dati della nuova applicazione: nomi dei campi, tipi, valori minimi e massimi, lunghezza, campi obbligatori, convalide a livello di campo ecc., in modo chiaro
• È necessario annotare un certo numero di tabelle nel sistema legacy e verificare se eventuali tabelle vengono eliminate e aggiunte dopo la migrazione.
• Un certo numero di record in ogni tabella, le viste devono essere annotate nell’applicazione legacy.
• Studia le interfacce nella nuova applicazione e le loro connessioni. I dati che scorrono nell’interfaccia devono essere altamente protetti e non interrotti.
• Prepara casi di test, scenari di test e casi d’uso per le nuove condizioni nelle nuove applicazioni.
• Esegui una serie di casi di test, scenari con un insieme di utenti e conserva i risultati, i registri archiviati. Lo stesso deve essere verificato dopo la migrazione per garantire che i dati e le funzionalità legacy siano intatti.
• Il conteggio dei dati e dei record deve essere annotato chiaramente, deve essere verificato dopo la migrazione per evitare perdite di dati.

Fase 2:  test di migrazione

La ” Guida alla migrazione”, preparata dal team di migrazione, deve essere rigorosamente seguita per svolgere l’attività di migrazione. Idealmente, l’attività di migrazione inizia con il backup dei dati sul nastro, in modo che, in qualsiasi momento, il sistema legacy possa essere ripristinato.

Anche la verifica della parte della documentazione della ” Guida alla migrazione” fa parte del test di migrazione dei dati . Verifica se il documento è chiaro e facile da seguire. Tutti gli script e i passaggi devono essere documentati correttamente senza alcuna ambiguità. Eventuali errori di documentazione, mancate corrispondenze nell’ordine di esecuzione dei passaggi devono anche essere considerati importanti affinché possano essere segnalati e corretti.

Gli script di migrazione, la guida e altre informazioni relative alla migrazione effettiva devono essere prelevati dal repository di controllo della versione per l’esecuzione.

Annotare il tempo effettivo impiegato per la migrazione dal punto di inizio della migrazione fino al corretto ripristino del sistema, è uno dei casi di test da eseguire e quindi il “Tempo impiegato per migrare il sistema” deve essere registrato nel finale rapporto di prova che verrà consegnato come parte dei risultati del test di migrazione e queste informazioni saranno utili durante il lancio della produzione. Il tempo di inattività registrato nell’ambiente di test viene estrapolato per calcolare il tempo di inattività approssimativo nel sistema attivo.

È sul sistema legacy che verrà svolta l’attività di Migrazione.

Durante questo test, tutti i componenti dell’ambiente verranno solitamente portati giù e rimossi dalla rete per svolgere le attività di Migrazione. Quindi è necessario annotare i “Tempi di inattività” richiesti per il test di migrazione. Idealmente, sarà lo stesso del tempo della migrazione.

In generale, l’attività di migrazione definita nel documento “Guida alla migrazione” include:

• Migrazione effettiva dell’applicazione
• Firewall, porte, host, hardware, configurazioni software sono tutti modificati in base al nuovo sistema su cui viene migrata l’eredità
• Fughe di dati, vengono eseguiti controlli di sicurezza
• Viene verificata la connettività tra tutti i componenti dell’applicazione

È consigliabile che i tester verifichino quanto sopra nel back-end del sistema o eseguendo il test della scatola bianca.

Una volta completata l’attività di Migrazione specificata nella guida, tutti i server vengono richiamati e verranno eseguiti i test di base relativi alla verifica della corretta migrazione, il che garantisce che tutti i sistemi end-to-end siano opportunamente collegati e che tutti i componenti parlino con ciascuno altro, DB è attivo e funzionante, il front-end sta comunicando correttamente con il back-end. Questi test devono essere identificati in anticipo e registrati nel documento delle specifiche del test di migrazione.

Ci sono possibilità che il software supporti più piattaforme diverse. In tal caso, la migrazione deve essere verificata separatamente su ciascuna di queste piattaforme.

La verifica degli script di migrazione farà parte del test di migrazione. A volte lo script di migrazione individuale viene verificato anche utilizzando il “test white box” in un ambiente di test autonomo.

Quindi i test di migrazione saranno una combinazione di “test della scatola bianca e della scatola nera”.

Una volta eseguita questa verifica relativa alla migrazione e superati i test corrispondenti, il team può procedere ulteriormente con l’attività di test post-migrazione.

Fase 3: test post-migrazione

Una volta che l’applicazione è stata migrata correttamente, entrano in gioco i test di post-migrazione.

Qui il test del sistema end-to-end viene eseguito nell’ambiente di test. I tester eseguono casi di test identificati, scenari di test, casi d’uso con dati legacy e un nuovo set di dati.

Oltre a questi, ci sono elementi specifici da verificare negli ambienti migrati che sono elencati di seguito:

Tutti questi sono documentati come test case e inclusi nel documento “Test Specification”.

1. Verifica se tutti i dati nell’eredità vengono migrati nella nuova applicazione entro il tempo di inattività pianificato. Per garantire ciò, confrontare il numero di record tra legacy e la nuova applicazione per ogni tabella e vista nel database. Inoltre, segnala il tempo impiegato per spostare diciamo 10000 record.
2. Verificare se tutte le modifiche allo schema (campi e tabelle aggiunti o rimossi) secondo il nuovo sistema sono state aggiornate.
3. I dati migrati dall’eredità alla nuova applicazione dovrebbero conservare il valore e il formato a meno che non sia specificato per farlo. Per garantire ciò, confrontare i valori dei dati tra il database legacy e quello della nuova applicazione.
4. Testare i dati migrati rispetto alla nuova applicazione. Qui copre un numero massimo di casi possibili. Per garantire una copertura del 100% rispetto alla verifica della migrazione dei dati, utilizzare lo strumento di test automatizzato.
5. Verifica la sicurezza del database.
6. Verificare l’integrità dei dati per tutti i possibili record di esempio.
7. Verificare e assicurarsi che la funzionalità supportata in precedenza nel sistema legacy funzioni come previsto nel nuovo sistema.
8. Controllare il flusso di dati all’interno dell’applicazione che copre la maggior parte dei componenti.
9. L’interfaccia tra i componenti dovrebbe essere testata in modo approfondito, poiché i dati non devono essere modificati, persi e danneggiati quando passano attraverso i componenti. I casi di test di integrazione possono essere utilizzati per verificarlo.
10. Verifica la ridondanza dei dati legacy. Nessun dato legacy deve essere duplicato durante la migrazione
11. Verificare la presenza di casi di mancata corrispondenza dei dati come il tipo di dati modificato, il formato di archiviazione modificato ecc.,
12. Tutti i controlli a livello di campo nell’applicazione legacy dovrebbero essere coperti anche nella nuova applicazione
13. Qualsiasi aggiunta di dati nella nuova applicazione non dovrebbe riflettere l’eredità
14. L’aggiornamento dei dati dell’applicazione legacy tramite la nuova applicazione dovrebbe essere supportato. Una volta aggiornato nella nuova applicazione, non dovrebbe riflettere sull’eredità.
15. L’eliminazione dei dati dell’applicazione legacy nella nuova applicazione dovrebbe essere supportata. Una volta eliminata nella nuova applicazione, non dovrebbe eliminare anche i dati in legacy.
16. Verificare che le modifiche apportate al sistema precedente supportino la nuova funzionalità fornita come parte del nuovo sistema.
17. Verifica che gli utenti del sistema legacy possano continuare a utilizzare sia la vecchia funzionalità che la nuova funzionalità, in particolare quelle in cui sono coinvolte le modifiche. Eseguire i test case ei risultati dei test archiviati durante il test di pre-migrazione.
18. Crea nuovi utenti sul sistema ed esegui test per garantire che le funzionalità dell’eredità e della nuova applicazione supportino gli utenti appena creati e funzionino correttamente.
19. Eseguire test relativi alla funzionalità con una varietà di campioni di dati (fascia di età diversa, utenti di regione diversa, ecc.)
20. È inoltre necessario verificare se i “Feature Flags” sono abilitati per le nuove funzionalità e l’attivazione/disattivazione delle funzionalità consente di attivare e disattivare le funzionalità.
21. Il test delle prestazioni è importante per garantire che la migrazione a un nuovo sistema/software non abbia ridotto le prestazioni del sistema.
22. È inoltre necessario eseguire prove di carico e di stress per garantire la stabilità del sistema.
23. Verificare che l’aggiornamento del software non abbia aperto vulnerabilità di sicurezza e quindi eseguire test di sicurezza, soprattutto nell’area in cui sono state apportate modifiche al sistema durante la migrazione.
24. L’usabilità è un altro aspetto da verificare, in cui se il layout della GUI/il sistema front-end è cambiato o se è cambiata qualsiasi funzionalità, qual è la facilità d’uso che l’utente finale sente rispetto al sistema legacy.

Poiché l’ambito dei test post-migrazione diventa molto vasto, è l’ideale separare i test importanti che devono essere eseguiti prima per qualificare che la migrazione ha esito positivo e poi per eseguire i restanti in un secondo momento.

È inoltre consigliabile automatizzare i casi di test funzionali end-to-end e altri possibili casi di test in modo da ridurre i tempi di test e ottenere rapidamente i risultati.

Alcuni suggerimenti per i tester per scrivere i casi di test per l’esecuzione post-migrazione:

• Quando l’applicazione viene migrata, non significa che i test case debbano essere scritti per l’intera nuova applicazione. I casi di test già progettati per l’eredità dovrebbero comunque essere validi per la nuova applicazione. Quindi, per quanto possibile, utilizza i vecchi casi di test e converti i casi di test legacy in casi di una nuova applicazione, ove necessario.
• In caso di modifiche alle funzionalità nella nuova applicazione, è necessario modificare i casi di test relativi alla funzionalità.
• Se sono state aggiunte nuove funzionalità nella nuova applicazione, è necessario progettare nuovi casi di test per quella particolare funzionalità.
• Quando si verifica un calo di funzionalità nella nuova applicazione, i casi di test dell’applicazione legacy correlata non devono essere presi in considerazione per l’esecuzione successiva alla migrazione e devono essere contrassegnati come non validi e mantenuti separati.
• I test case progettati dovrebbero essere sempre affidabili e coerenti in termini di utilizzo. La verifica dei dati critici dovrebbe essere inclusa nei casi di test in modo che non vengano persi durante l’esecuzione.
• Quando la progettazione della nuova applicazione è diversa da quella della legacy (UI), i test case relativi all’interfaccia utente devono essere modificati per adattare la nuova progettazione. La decisione di aggiornare o di scriverne di nuovi, in questo caso, può essere presa dal tester in base al volume delle modifiche avvenute.

Test di compatibilità con le versioni precedenti

La migrazione del sistema richiede anche ai tester di verificare la ‘Compatibilità con le versioni precedenti’, in cui il nuovo sistema introdotto è compatibile con il vecchio sistema (almeno 2 versioni precedenti) e garantisce il perfetto funzionamento con quelle versioni.

La retrocompatibilità serve a garantire:

1. Se il nuovo sistema supporta la funzionalità supportata nelle 2 versioni precedenti insieme a quella nuova.
2. Il sistema può essere migrato con successo dalle 2 versioni precedenti senza problemi.

Pertanto è fondamentale garantire la compatibilità con le versioni precedenti del sistema eseguendo specificamente i test relativi al supporto della compatibilità con le versioni precedenti. I test relativi alla compatibilità con le versioni precedenti devono essere progettati e inclusi nel documento Test Specification per l’esecuzione.

Test di rollback

In caso di problemi durante l’esecuzione della migrazione o se si verifica un errore di migrazione in qualsiasi momento durante la migrazione, dovrebbe essere possibile per il sistema tornare al sistema legacy e riprendere rapidamente la sua funzione senza influire sugli utenti e la funzionalità supportata in precedenza.

Pertanto, per verificare ciò, è necessario progettare scenari di test di errore di migrazione come parte del test negativo e testare il meccanismo di rollback. Anche il tempo totale necessario per tornare al sistema precedente deve essere registrato e riportato nei risultati del test.

Dopo il rollback, è necessario eseguire la funzionalità principale e il test di regressione (automatizzato) per garantire che la migrazione non abbia alcun impatto e che il rollback riesca a ripristinare il sistema legacy.

Sfide nei test di migrazione dei dati

Le sfide affrontate in questo test riguardano principalmente i dati. Di seguito sono riportati alcuni nell’elenco.

Qualità dei dati

È possibile che i dati utilizzati nell’applicazione legacy siano di scarsa qualità nell’applicazione nuova/aggiornata. In questi casi, la qualità dei dati deve essere migliorata per soddisfare gli standard aziendali.

Fattori come ipotesi, conversioni dei dati dopo le migrazioni, dati inseriti nell’applicazione legacy stessa non sono validi, un’analisi dei dati scadente, ecc. Porta a una qualità dei dati scadente. Ciò si traduce in costi operativi elevati, maggiori rischi di integrazione dei dati e deviazione dallo scopo aziendale.

Mancata corrispondenza dei dati

I dati migrati dall’eredità all’applicazione nuova/aggiornata potrebbero non corrispondere a quella nuova. Ciò può essere dovuto al cambiamento del tipo di dati, al formato di archiviazione dei dati, allo scopo per cui i dati vengono utilizzati può essere ridefinito.

Ciò si traduce in un enorme sforzo per modificare le modifiche necessarie per correggere i dati non corrispondenti o accettarli e ottimizzarli a tale scopo.

Perdita di dati

I dati potrebbero andare persi durante la migrazione dall’eredità all’applicazione nuova/aggiornata. Questo può essere con campi obbligatori o non obbligatori. Se i dati persi riguardano campi non obbligatori, il relativo record sarà ancora valido e potrà essere nuovamente aggiornato.

Ma se i dati del campo obbligatorio vengono persi, il record stesso diventa nullo e non può essere ritirato. Ciò comporterà un’enorme perdita di dati e dovrebbe essere recuperato dal database di backup o dai registri di controllo se acquisiti correttamente.

VOLUME DEI DATI

Enormi dati che richiedono molto tempo per la migrazione all’interno della finestra di inattività dell’attività di migrazione. Ad esempio: gratta e vinci nel settore delle telecomunicazioni, utenti su una piattaforma di rete intelligente ecc., qui la sfida è che nel tempo, i dati legacy vengono cancellati, verranno creati nuovi enormi dati, che devono essere nuovamente migrati. L’automazione è la soluzione per un’enorme migrazione di dati.

Simulazione di un ambiente in tempo reale (con i dati effettivi)

La simulazione di un ambiente  in tempo reale nel laboratorio di test è un’altra vera sfida, in cui i tester affrontano diversi tipi di problemi con i dati reali e il sistema reale, che non vengono affrontati durante il test.

Pertanto, il campionamento dei dati, la replica dell’ambiente reale, l’identificazione del volume dei dati coinvolti nella migrazione sono piuttosto importanti durante l’esecuzione dei test di migrazione dei dati.

Simulazione del volume di dati

I team devono studiare i dati nel sistema live con molta attenzione e dovrebbero elaborare l’analisi e il campionamento tipici dei dati.

Ad esempio.: utenti con fascia di età inferiore a 10 anni, 10-30 anni ecc., Per quanto possibile, è necessario ottenere i dati dal vivo, altrimenti la creazione dei dati deve essere eseguita nell’ambiente di test. È necessario utilizzare strumenti automatizzati per creare un grande volume di dati. L’estrapolazione, ove applicabile, può essere utilizzata se il volume non può essere simulato.

Suggerimenti per ridurre i rischi di migrazione dei dati

Di seguito sono riportati alcuni suggerimenti da adottare per smussare i rischi di migrazione dei dati:

• Standardizzare i dati utilizzati nel sistema legacy, in modo che, una volta migrati, i dati standard siano disponibili nel nuovo sistema
• Migliora la qualità dei dati, in modo che una volta migrati, ci siano dati qualitativi da testare dando la sensazione di testare come utente finale
• Pulisci i dati prima della migrazione, in modo che durante la migrazione, i dati duplicati non siano presenti nel nuovo sistema e anche questo mantenga pulito l’intero sistema
• Ricontrolla i vincoli, le procedure memorizzate, le query complesse che producono risultati accurati, in modo che, una volta migrati, i dati corretti vengano restituiti anche nel nuovo sistema
• Identificare lo strumento di automazione corretto per eseguire i controlli dei dati/registrazioni nel nuovo sistema rispetto al precedente.

Conclusioni

Pertanto, considerata la complessità dell’esecuzione del test di migrazione dei dati, tenendo presente che una piccola mancata verifica in qualsiasi aspetto durante il test comporterà il rischio di una mancata migrazione in produzione, è molto importante effettuare uno studio (attento e approfondito) e analisi del sistema prima e dopo la migrazione. Pianifica e progetta l’efficace strategia di migrazione con gli strumenti robusti insieme a tester qualificati e formati.

Poiché sappiamo che la migrazione ha un enorme impatto sulla qualità dell’applicazione, l’intero team deve impegnarsi per verificare l’intero sistema in tutti gli aspetti come funzionalità, prestazioni, sicurezza, usabilità, disponibilità, affidabilità, compatibilità ecc., che a sua volta garantiranno il successo dei test di migrazione.