Test di integrazione di sistema nel software testing: guida 2026
19 luglio 2026
TL;DR:
- Il test di integrazione del sistema verifica che più componenti software e dipendenze esterne funzionino correttamente insieme come un sistema unificato. Si concentra sul test delle interfacce, dei flussi di dati e dei protocolli di comunicazione che emergono solo quando i moduli sono assemblati, prevenendo guasti costosi in produzione.
Cos'è il test di integrazione del sistema nel testing del software?
Il testing di integrazione del sistema (SIT) è il processo di verifica che più componenti software, sottosistemi e dipendenze esterne operino insieme correttamente come un sistema unificato. Mentre il test unitario convalida i singoli moduli in isolamento, il SIT esamina le interfacce, i flussi di dati, i protocolli di comunicazione e il comportamento collettivo che emergono solo quando tali moduli sono assemblati. La distinzione è importante perché il solo test unitario non può prevedere come i componenti interagiranno in condizioni reali, e i difetti che emergono ai confini dell'integrazione sono frequentemente i più dannosi in produzione.
Il SIT si colloca tra il testing di sistema dei singoli componenti e il testing di accettazione dell'utente (UAT) nel ciclo di vita del testing del software. I fornitori di software in genere eseguono un giro pre-SIT internamente prima di consegnare i casi di test al cliente o al consumatore. L'ambito del SIT si estende oltre il testing di integrazione tradizionale: comprende l'intero ecosistema software, incluse API esterne, servizi di terze parti, piattaforme legacy e database condivisi, non solo le interazioni interne modulo-modulo che le fasi precedenti affrontano.
Aspetti chiave del SIT:
- Convalida lo scambio di dati tra livelli integrati: livello di integrazione, livello di database e livello di applicazione
- Testa protocolli di comunicazione, trasformazioni middleware e mappatura dei dati attraverso i confini del sistema
- Verifica i flussi di transazione end-to-end, inclusi percorsi di errore e casi limite
- Copre sia la correttezza funzionale che il comportamento non funzionale come latenza e sicurezza
- Precede l'UAT e segue il completamento con successo dei test unitari e a livello di componente
- Si applica ugualmente a combinazioni hardware-software, sistemi puramente software e architetture "human-in-the-loop"
Perché il SIT è fondamentale per la qualità del software
Circa il 70% dei guasti ai sistemi software deriva da problemi di integrazione, rendendo il SIT una delle attività con il più alto potenziale in qualsiasi programma di assicurazione qualità. I difetti rilevati al confine dell'integrazione sono ordini di grandezza più economici da correggere rispetto a quelli scoperti in produzione, dove i guasti a cascata attraverso sistemi interconnessi aggravano sia l'impatto tecnico che quello commerciale.
Il SIT verifica flussi di lavoro end-to-end che abbracciano confini organizzativi e tecnici: un gateway di pagamento che comunica con un sistema di gestione degli ordini, un ERP legacy che scambia record con un CRM cloud-native, o un cluster di microservizi che gestisce richieste API concorrenti. Questi flussi di lavoro non possono essere convalidati da alcuna fase di test precedente. Oltre alla correttezza funzionale, problemi di integrazione non funzionali come colli di bottiglia di latenza e disallineamenti dei permessi di sicurezza possono essere rilevati realisticamente solo durante il SIT, rendendolo il principale punto di controllo per le prestazioni e la sicurezza al confine del sistema.
Per progetti complessi, multi-vendor o integrati con sistemi legacy, la posta in gioco è particolarmente alta. Un singolo token di autenticazione mal configurato o un vincolo di lunghezza di campo non documentato in un database legacy può corrompere i dati silenziosamente in tutto il sistema. Il SIT rileva queste condizioni prima che raggiungano gli utenti.
Criteri di ingresso e uscita per il SIT
Criteri di ingresso e uscita chiari prevengono due fallimenti comuni: iniziare il SIT prima che il sistema sia pronto e dichiararlo completo prima che il rischio sia stato realmente ridotto. I criteri di ingresso per il SIT includono test unitari completati e prontezza dell'ambiente; i criteri di uscita richiedono che tutti i casi di test pianificati siano stati eseguiti, i difetti risolti e l'approvazione degli stakeholder ottenuta.
Criteri di ingresso:
- Tutti i moduli costituenti hanno superato i test unitari e la verifica a livello di componente
- L'ambiente di test integrato è configurato e stabile, rispecchiando la topologia di produzione
- I set di dati di test sono preparati e approvati, inclusi, ove richiesto, sottoinsiemi di produzione anonimizzati
- I punti di integrazione, le API e le specifiche dell'interfaccia sono documentati e concordati
- I piani di test, i casi di test e le matrici di tracciabilità sono stati revisionati e approvati
Criteri di uscita:
- Tutti i casi di test SIT pianificati sono stati eseguiti rispetto all'ambito concordato
- I tassi di chiusura dei difetti soddisfano la soglia concordata, senza difetti critici o ad alta gravità aperti
- La copertura di test soddisfa il minimo definito attraverso scenari funzionali e non funzionali
- I test di regressione confermano che le correzioni dei difetti non hanno introdotto nuovi guasti
- L'approvazione degli stakeholder e la documentazione formale sono complete, autorizzando la progressione all'UAT
Tipi e approcci al testing di integrazione del sistema
Gli approcci di test Incrementale, Big Bang e Ibrido offrono diversi equilibri tra velocità e isolamento dei difetti, selezionati in base alla complessità del progetto, alla struttura del team e alle tempistiche di consegna.
Il test di integrazione incrementale aggiunge e testa i componenti progressivamente, in modalità top-down (partendo dai moduli di alto livello e "stubando" quelli inferiori), bottom-up (partendo dai moduli di basso livello con driver che simulano i livelli superiori) o in una combinazione di entrambi. Questo approccio isola i difetti in modo più preciso perché ogni aggiunta introduce un insieme delimitato di nuove interazioni. È adatto a sistemi grandi e complessi in cui il rilevamento precoce dei guasti riduce i costi di rilavorazione.
Il test di integrazione "Big Bang" assembla tutti i componenti contemporaneamente e testa l'intero sistema in una sola volta. L'approccio è più veloce da configurare e funziona in modo accettabile per sistemi più piccoli con una complessità di integrazione limitata. Il suo significativo svantaggio è che la localizzazione dei difetti diventa difficile quando più interfacce falliscono contemporaneamente, poiché non esiste una base di riferimento incrementale con cui confrontarsi.
Il test di integrazione ibrido (a sandwich) combina strategie top-down e bottom-up, testando i sottosistemi critici in parallelo. Questo è adatto a progetti con livelli architetturali ben definiti e flussi di sviluppo indipendenti, consentendo ai team di progredire senza attendere l'assemblaggio dell'intero sistema.
Criteri che influenzano la selezione del metodo:
- Complessità del sistema e numero di punti di integrazione
- Struttura del team e se i flussi di sviluppo sono paralleli o sequenziali
- Tempistica di consegna e tolleranza per lo sforzo di localizzazione dei difetti
- Disponibilità di stub, driver e test harness per l'assemblaggio parziale
Come eseguire il SIT: processo ed esempio pratico
L'esecuzione efficace del SIT richiede una sequenza strutturata che va dall'identificazione all'esecuzione, fino alla chiusura verificata. Il processo si applica sia che il team stia testando un'integrazione API REST tra due microservizi o una piattaforma aziendale completa che connette sistemi ERP, CRM e di pagamento.
Step 1: Identificare i punti di integrazione. Mappare ogni interfaccia in cui i dati attraversano un confine di sistema: endpoint API, argomenti di code di messaggi, connessioni a database, meccanismi di trasferimento file e handshake di autenticazione. Ogni punto di integrazione diventa un obiettivo di test.
Step 2: Sviluppare scenari di test. Scrivere casi di test che coprano il percorso normale, le condizioni di errore, i valori limite e gli scenari di concorrenza per ogni punto di integrazione. Un'integrazione di elaborazione dei pagamenti, ad esempio, richiede casi di test per transazioni riuscite, carte rifiutate, timeout di rete, gestione di invii duplicati e casi limite di conversione di valuta.
Step 3: Configurare l'ambiente di test. Configurare l'infrastruttura per rispecchiare il più fedelmente possibile la produzione, inclusa la topologia di rete, i servizi di autenticazione e gli schemi di database. La parità dell'ambiente è il punto di fallimento più comune nel SIT: differenze nella configurazione di rete o nell'autenticazione tra ambienti di test e di produzione fanno sì che i test superino in anticipo ma falliscano successivamente nella distribuzione.
Step 4: Eseguire i casi di test. Eseguire test manuali e automatici, acquisendo i risultati effettivi rispetto a quelli attesi per ogni scenario. Registrare ogni difetto con dettagli sufficienti: il punto di integrazione, i dati di input, il comportamento osservato e il comportamento atteso.
Step 5: Segnalare, ritestare e chiudere. Tracciare i difetti fino alla risoluzione, ritestare le correzioni e confermare che le suite di regressione rimangano "verdi" prima di passare alla revisione dei criteri di uscita.
Suggerimento Pro: Non fare mai affidamento esclusivamente su dati sintetici durante il SIT. L'uso di sottoinsiemi anonimizzati di dati di produzione è fondamentale per rilevare problemi di volume di dati e casi limite che i set di dati sintetici mascherano completamente.
Un esempio pratico: un integratore aggiunge un nuovo livello applicativo e un livello di database al sistema esistente di un cliente. Dopo l'integrazione, sia le parti nuove che quelle legacy dell'applicazione devono scambiare importazioni ed esportazioni di dati, mantenendo entrambi i sistemi sincronizzati. Il SIT convalida che questo processo di scambio dati funzioni correttamente in tutte le condizioni definite, incluso il recupero da guasti.
Strumenti popolari per il test di integrazione di sistema
I moderni strumenti SIT supportano l'integrazione multi-piattaforma, inclusi i sistemi legacy, e offrono automazione insieme a capacità di integrazione della pipeline CI/CD. Lo strumento giusto dipende dall'architettura del sistema, dalla toolchain esistente del team e dal grado di automazione richiesto.
BrowserStack fornisce un'infrastruttura di test cross-browser e cross-platform basata su cloud, consentendo ai team SIT di convalidare le integrazioni su dispositivi e browser reali senza dover mantenere farm di dispositivi locali. I suoi prodotti Automate e App Automate si integrano con le pipeline CI/CD tramite Jenkins, GitHub Actions e CircleCI, rendendolo adatto per scenari di integrazione di applicazioni web in cui i sistemi front-end e back-end devono essere convalidati insieme in condizioni realistiche.
Postman è lo standard de facto per il test di integrazione API, offrendo raccolte, ambienti e runner di test automatizzati che si mappano direttamente sui flussi di lavoro SIT. La sua capacità di concatenare richieste, convalidare schemi di risposta e simulare dipendenze esterne lo rende efficace per testare i punti di integrazione REST e GraphQL in modo incrementale.
SoapUI affronta l'integrazione di servizi SOAP e REST, con supporto integrato per il testing basato sui dati, la scansione di sicurezza e la simulazione del carico. È adatto per ambienti aziendali in cui coesistono web service legacy e API moderne.
Apache JMeter va oltre il testing delle prestazioni, estendendosi alla validazione dell'integrazione funzionale, in particolare per scenari ad alta concorrenza in cui code di messaggi, connessioni a database ed endpoint API devono essere testati contemporaneamente sotto carico.
Katalon Studio combina il testing di API, web e mobile in un'unica piattaforma con creazione di test low-code e integrazione CI/CD, rendendolo accessibile a team che necessitano di coprire più livelli di integrazione senza una profonda esperienza di scripting.
| Strumento | Caso d'uso primario | Integrazione CI/CD | Supporto per sistemi legacy |
|---|---|---|---|
| BrowserStack | SIT web e app multipiattaforma | Sì (Jenkins, GitHub Actions) | Parziale |
| Postman | Testing API REST e GraphQL | Sì (Newman CLI) | Limitato |
| SoapUI | Servizi aziendali SOAP e REST | Sì | Forte |
| Apache JMeter | Integrazione funzionale e del carico | Sì | Forte |
| Katalon Studio | API, web, mobile multilivello | Sì | Moderato |
Approfondimenti di esperti sulle migliori pratiche SIT e le sfide comuni
Il SIT non è semplicemente il testing di integrazione ripetuto, ma una disciplina distinta focalizzata sull'intero ecosistema del sistema. Nelle architetture a microservizi, dove i singoli servizi vengono distribuiti indipendentemente e frequentemente, il SIT automatizzato è sempre più essenziale per preservare continuamente la stabilità del sistema, piuttosto che individuare le regressioni solo al momento del rilascio.
Errori comuni e come affrontarli:
- Incoerenza dell'ambiente: Differenze nella configurazione di rete, nella configurazione dell'autenticazione o nello schema del database tra gli ambienti di test e di produzione fanno sì che il SIT superi i test in isolamento ma fallisca nella distribuzione. Mantenere definizioni di infrastruttura-come-codice per l'ambiente SIT e convalidare la parità prima di ogni ciclo di test.
- Guasti di dipendenza dai dati: I test che dipendono da uno stato di dati specifico lasciato da un test precedente creano suite fragili e dipendenti dall'ordine. Progettare ogni caso di test per impostare e smantellare il proprio stato di dati in modo indipendente.
- Copertura non funzionale insufficiente: La latenza sotto carico concorrente, le discrepanze nelle autorizzazioni di sicurezza e l'esaurimento del pool di connessioni sono problemi a livello di integrazione che i soli casi di test funzionali non faranno emergere. Includere scenari di prestazioni e sicurezza in ogni ciclo SIT.
- Aumento incontrollato dell'ambito al confine: Senza criteri di ingresso e uscita concordati, il SIT si espande per assorbire difetti che appartengono ai test unitari o di sistema, distorcendo le tempistiche e oscurando il rischio di integrazione genuino.
- Eccessivo affidamento sui dati sintetici: Il testing sui dati sintetici maschera i casi limite; i sottoinsiemi di dati di produzione anonimizzati espongono variazioni realistiche di volume e formato che i set sintetici non possono replicare.
Vicedomini Softworks applica test mirati e con revisione tra pari a ogni livello di integrazione, combinando pipeline SIT automatizzate con osservabilità di livello di produzione per rilevare le regressioni dell'interfaccia prima che raggiungano la distribuzione. Il loro modello di ingegnere diretto significa che lo stesso team che costruisce l'integrazione è anche proprietario della sua copertura di test, eliminando le lacune di conoscenza che tipicamente producono i difetti SIT più costosi.
Configurazione di un ambiente di test per SIT
L'ambiente di test per SIT deve rispecchiare fedelmente l'ambiente di produzione, coprendo la configurazione hardware, le versioni del software, la topologia di rete, i servizi di autenticazione e gli schemi del database. Qualsiasi divergenza introduce il rischio che i test superino nell'ambiente SIT ma falliscano in produzione, che è precisamente la modalità di fallimento che il SIT è progettato per prevenire.
Strumenti di infrastruttura-come-codice come Terraform e Ansible consentono ai team di definire l'ambiente SIT in modo dichiarativo, di controllarne la versione insieme al codice dell'applicazione e di ricostruirlo in modo coerente per ogni ciclo di test. L'orchestrazione di container tramite Kubernetes, come utilizzato negli ambienti SIT cloud-native, consente un provisioning dell'ambiente riproducibile e isolato dalle altre fasi di test. Strumenti di virtualizzazione dei servizi come WireMock o Hoverfly consentono ai team di simulare dipendenze esterne non disponibili o troppo costose da includere nell'ambiente SIT, senza sacrificare la fedeltà dell'interfaccia.
La configurazione dell'autenticazione e dell'autorizzazione merita particolare attenzione. Le differenze negli ambiti dei token OAuth, nelle autorizzazioni delle chiavi API o nel controllo degli accessi basato sui ruoli tra gli ambienti di test e di produzione sono una causa principale dei fallimenti SIT che non si riproducono in isolamento.
Approcci alla gestione dei dati di test in SIT
La gestione dei dati di test in SIT è più impegnativa rispetto al testing unitario o dei componenti perché i dati devono riflettere la piena complessità delle interazioni di sistema reali, inclusi volume, variazione di formato e integrità referenziale tra sistemi. I dati sintetici sono insufficienti per questo scopo: non possono replicare i casi limite e le caratteristiche di volume che i dati di produzione espongono.
L'approccio consigliato consiste nell'utilizzare sottoinsiemi anonimi di dati di produzione, elaborati attraverso una pipeline di mascheramento dei dati che rimuove le informazioni di identificazione personale preservando le proprietà strutturali e statistiche. Strumenti come Delphix o IBM InfoSphere Optim supportano questo flusso di lavoro su scala aziendale. Per i sistemi soggetti al GDPR o ad altre normative sulla protezione dei dati, il processo di mascheramento deve essere verificabile e il set di dati anonimi deve essere convalidato per confermare che la re-identificazione non è possibile.
La gestione dello stato dei dati tra i casi di test richiede disciplina. Ogni caso di test dovrebbe predisporre le proprie precondizioni sui dati e pulire dopo l'esecuzione, prevenendo perdite di stato che causano errori intermittenti. Per le integrazioni basate su database, il rollback transazionale o i meccanismi di ripristino istantaneo forniscono un meccanismo di ripristino affidabile tra le esecuzioni dei test.
Strategie per automatizzare i test di integrazione del sistema
L'automazione è l'unica strategia praticabile per mantenere la copertura SIT in sistemi che cambiano frequentemente, in particolare quelli costruiti su microservizi o architetture basate su eventi dove i singoli componenti vengono distribuiti indipendentemente. I cicli SIT manuali non possono tenere il passo con le pipeline di continuous delivery.
La base di un'efficace strategia SIT automatizzata è una suite di test ben strutturata organizzata attorno a contratti di integrazione anziché a dettagli di implementazione. Framework di test contrattuali come Pact consentono ai team di consumatori e provider di definire e verificare gli accordi di interfaccia in modo indipendente, rilevando i cambiamenti che causano interruzioni prima che raggiungano un ambiente condiviso. Questo approccio è particolarmente efficace per le integrazioni basate su REST e messaggi, dove i team distribuiscono in modo asincrono.
Le suite SIT automatizzate dovrebbero essere integrate nella pipeline CI/CD alla fase appropriata: tipicamente dopo la distribuzione in un ambiente di staging che rispecchia la produzione. L'integrazione della pipeline tramite Jenkins, GitHub Actions o GitLab CI assicura che ogni distribuzione attivi la suite di test di integrazione pertinente, con i risultati riportati al team prima della promozione all'ambiente successivo. L'esecuzione dei test dovrebbe essere parallelizzata ove possibile per mantenere brevi i cicli di feedback, e i test fluttuanti dovrebbero essere isolati e investigati immediatamente anziché essere tollerati come rumore di fondo.
Gestione delle dipendenze e dei problemi di interfaccia durante il SIT
La gestione delle dipendenze è uno degli aspetti operativamente più complessi del SIT, in particolare nei sistemi che si integrano con servizi di terze parti, piattaforme legacy o API esterne che non sono sotto il controllo del team. Quando una dipendenza non è disponibile, instabile o proibitiva in termini di costi per essere inclusa nell'ambiente di test, la virtualizzazione dei servizi fornisce un sostituto controllato che replica il comportamento dell'interfaccia senza richiedere il sistema reale.
I problemi di interfaccia sorgono più comunemente da ipotesi non documentate: un campo che un sistema invia come stringa e un altro si aspetta come intero, un formato di timestamp che differisce tra i fusi orari o un contratto di paginazione che si interrompe quando i set di risultati superano una soglia. La specifica formale dell'interfaccia utilizzando OpenAPI, AsyncAPI o WSDL riduce queste ambiguità rendendo il contratto esplicito e verificabile automaticamente. Durante l'integrazione di sistemi legacy, la documentazione dell'interfaccia è spesso incompleta o imprecisa, richiedendo test esplorativi per stabilire il contratto effettivo prima che possano essere scritti casi di test formali.
Le discrepanze di versione delle dipendenze tra i componenti integrati sono un'altra fonte comune di fallimenti SIT. Mantenere una matrice delle dipendenze che registri le combinazioni di versioni testate per ogni punto di integrazione fornisce un riferimento per la diagnosi dei fallimenti e la pianificazione dei percorsi di aggiornamento.
Reportistica e metriche per valutare l'efficacia del SIT
La reportistica SIT deve fornire agli stakeholder una visione chiara e basata su prove del rischio di integrazione in qualsiasi punto del ciclo di test. Le metriche più importanti sono quelle che riflettono direttamente la salute dell'integrazione in fase di test, non il volume delle attività.
Metriche SIT chiave:
| Metrica | Cosa misura |
|---|---|
| Tasso di esecuzione dei casi di test | Percentuale di casi di test pianificati eseguiti rispetto allo scopo totale |
| Tasso di rilevamento dei difetti | Numero di difetti trovati per ciclo di test, tendenza nel tempo |
| Distribuzione della gravità dei difetti | Proporzione di difetti critici, elevati, medi e di bassa gravità |
| Tasso di chiusura dei difetti | Percentuale di difetti segnalati risolti entro il ciclo |
| Copertura del test per punto di integrazione | Copertura di ogni interfaccia identificata rispetto al piano di test |
| Tasso di stabilità dell'ambiente | Percentuale di fallimenti dei test attribuibili a problemi ambientali piuttosto che a difetti dell'applicazione |
La distribuzione della gravità dei difetti è particolarmente informativa: un'alta proporzione di difetti critici in ritardo nel ciclo SIT indica che i criteri di ingresso non sono stati applicati rigorosamente, o che il sistema non era sufficientemente stabile quando è iniziato il test. Il tasso di stabilità dell'ambiente separa i difetti genuini dell'applicazione dal rumore dell'infrastruttura, il che è essenziale per una valutazione accurata del rischio.
I report dovrebbero essere prodotti con una cadenza che corrisponda al ritmo di consegna, quotidianamente durante l'esecuzione attiva dei test e riepilogati ad ogni milestone. La tracciabilità dai casi di test ai requisiti e dai difetti ai punti di integrazione consente agli stakeholder di valutare il rischio residuo con precisione, anziché basarsi solo sui tassi di successo aggregati.
Punti chiave
Il test di integrazione del sistema è il meccanismo principale per rilevare difetti di interfaccia, fallimenti del flusso di dati e problemi di integrazione non funzionale che nessuna fase di test precedente può evidenziare.
| Punto | Dettagli |
|---|---|
| L'ambito del SIT supera il test di integrazione | Il SIT copre l'intero ecosistema del sistema, incluse API esterne, piattaforme legacy e database condivisi, non solo le interazioni tra moduli interni. |
| I problemi di integrazione rappresentano circa il 70% di tutti i fallimenti dei sistemi software, sottolineando l'importanza cruciale del SIT per il rilevamento precoce dei difetti e il miglioramento della qualità del sistema. | |
| La parità dell'ambiente è fondamentale | Le differenze tra gli ambienti di test e di produzione fanno sì che il SIT superi la fase iniziale ma fallisca nel deployment; l'infrastruttura come codice e la virtualizzazione dei servizi mitigano questo rischio. |
| Sono necessari dati di produzione anonimizzati | I dati sintetici mascherano i casi limite; i sottoinsiemi di produzione anonimizzati espongono variazioni realistiche di volume e formato che i set di dati sintetici non possono replicare. |
| Automatizzare il SIT all'interno delle pipeline CI/CD | Il SIT automatizzato continuo è essenziale nelle architetture a microservizi dove frequenti deployment richiedono una convalida continua dell'interfaccia per preservare l'integrità del sistema. |
FAQ
Cos'è il system integration testing (SIT) nel testing del software?
Il system integration testing (SIT) è il processo di verifica che più componenti software, sottosistemi e dipendenze esterne funzionino correttamente insieme come un sistema unificato, testando interfacce, flussi di dati e protocolli di comunicazione che emergono solo quando i componenti sono assemblati. Si colloca tra il testing a livello di componente e il testing di accettazione dell'utente nel ciclo di vita del testing del software.
Quali sono i quattro tipi di testing di integrazione?
I quattro approcci principali sono l'integrazione top-down (test da moduli di alto livello verso il basso utilizzando stub), l'integrazione bottom-up (test da moduli di basso livello verso l'alto utilizzando driver), l'integrazione Big Bang (assemblaggio simultaneo di tutti i componenti) e l'integrazione ibrida o a sandwich (che combina strategie top-down e bottom-up per sistemi complessi).
Quali sono i principali tipi di system testing?
Il system testing comprende il functional testing (verifica che il sistema soddisfi i requisiti specificati), il performance testing (valutazione della produttività, latenza e scalabilità), il security testing (validazione dei controlli di accesso e dell'esposizione a vulnerabilità), l'usability testing (valutazione dell'esperienza utente) e il regression testing (conferma che le modifiche non abbiano compromesso le funzionalità esistenti).
Qual è un esempio di testing di integrazione nel testing del software?
Un esempio pratico è un integratore che aggiunge un nuovo livello applicativo e un livello database al sistema esistente di un cliente: il SIT convalida che le importazioni e le esportazioni di dati tra i nuovi e i vecchi livelli funzionino correttamente in tutte le condizioni definite, inclusi il recupero da guasti e l'accesso concorrente, mantenendo entrambi i sistemi sincronizzati.