Questo articolo spiega le differenze chiave tra SIT e UAT. Imparerai anche i metodi di System Integration Testing e User Acceptance Testing:
In generale, i test sono fatti sia dai tester che dagli sviluppatori. Ognuno di loro segue il proprio modello per testare un’applicazione.
Il System Integration Testing o SIT è fatto dai tester mentre lo User Acceptance Testing, comunemente conosciuto come UAT è fatto infine dagli utenti finali. Questo articolo confronterà entrambi i SIT e UAT in dettaglio e vi aiuterà a capire le differenze chiave tra i due.
Esploriamo!
SIT Vs UAT: Panoramica
In generale, i livelli di test hanno la seguente gerarchia:
- Unit testing
- Component testing
- System testing
- System integration testing
- User acceptance testing
- Production
Analizziamo le differenze chiave tra il System Integration Testing (SIT) e lo User Acceptance Testing (UAT).
System Integration Testing (SIT)
Due diversi sottosistemi/sistemi si combinano ad un certo punto in qualsiasi progetto. Dobbiamo poi testare questo sistema come un tutto. Quindi questo è chiamato System Integration Testing.
Fasi di lavoro del SIT
- Le singole unità devono essere integrate prima in builds separate.
- L’intero sistema deve essere testato nel suo insieme.
- I casi di test devono essere scritti usando un software appropriato basato sui requisiti del software.
- Gli errori come gli errori di UI, gli errori di flusso di dati, gli errori di interfaccia possono essere trovati in questo test.
Esempio:
Consideriamo che un sito di assistenza sanitaria abbia inizialmente 3 schede cioè Informazioni sul paziente, Educazione, Cartelle mediche precedenti. Il sito sanitario ha ora aggiunto una nuova scheda chiamata Informazioni sull’iniezione.
Ora i dettagli o il database della nuova scheda devono essere fusi con le schede esistenti e il sistema deve essere testato nel suo insieme con 4 schede.
Dobbiamo testare il sito integrato che ha quattro schede.
Il sito integrato appare come mostrato qui sotto:
Tecniche usate nel SIT
- Approccio top-down
- Approccio bottom-up
- Approccio big bang
#1) Approccio top-Down Approach
Come suggerisce il nome stesso significa che segue l’esecuzione dall’alto verso il basso. È un metodo in cui la funzionalità principale o il modulo viene testato seguito dai moduli secondari in ordine. Qui, sorge una domanda su cosa faremo se i sottomoduli consecutivi effettivi non sono presenti immediatamente per l’integrazione.
La risposta a questo dà luogo a STUBS.
Stubs sono conosciuti come programmi chiamati. Agiscono come moduli fittizi ed eseguono la funzione del modulo richiesto in modo limitato.
Gli stub eseguono la funzionalità di un’unità/modulo/sotto-modulo in modo parziale fino a quando il modulo effettivo non è pronto per l’integrazione, poiché l’integrazione dei sotto-moduli è difficile.
I componenti di basso livello possono essere sostituiti da stub per l’integrazione. Quindi l’approccio top-down può seguire un linguaggio strutturato o di procedura. Dopo che uno stub è stato sostituito con il componente effettivo, lo stub successivo può essere sostituito con i componenti effettivi.
L’esecuzione del diagramma precedente sarà modulo A, modulo B, modulo C, modulo D, modulo E, modulo F, modulo G.
Esempio per gli stub:
#2) Approccio Bottom-Up
Questo approccio segue la gerarchia bottom to top. Qui, i moduli più bassi sono integrati per primi e poi i moduli più alti sono integrati e testati.
I moduli o le unità più basse sono unite e testate. L’insieme delle unità inferiori sono chiamate Cluster. Mentre si integrano i sottomoduli con il modulo principale, nel caso in cui il modulo principale non sia disponibile, i DRIVER vengono usati per codificare il programma principale.
I DRIVER sono chiamati programmi chiamanti.
La perdita di difetti è minore in questo approccio.
Per integrare i sottomoduli ad un livello superiore o modulo principale viene creato un modulo driver come mostrato nella figura precedente.
#3) Approccio Big Bang
In parole semplici, nell’approccio Big Bang, è necessario collegare tutte le unità in una volta sola e testare tutti i componenti. Qui non si fa nessuna partizione. La perdita di difetti non deve verificarsi.
Questo approccio è utile per i progetti appena sviluppati da zero o per quelli che hanno subito importanti miglioramenti.
User Acceptance Testing (UAT)
Quando un tester consegna il progetto completato e testato al cliente/utente finale, il cliente/utente finale testa nuovamente il progetto per vedere se è stato progettato correttamente. Questo si chiama User Acceptance Testing.
Casi di test appropriati devono essere scritti per entrambi per eseguire i test.
Gli sviluppatori sviluppano un codice basato sul documento Functional Requirement Specification. I tester lo testano e segnalano i bug. Ma il cliente o l’utente finale sa solo come funziona esattamente il sistema. Quindi testano il sistema dalla loro parte.
Fasi di lavoro di UAT
- Il piano UAT deve essere creato sulla base dei requisiti.
- Gli scenari devono essere costruiti dai requisiti.
- I casi di test e i dati di test devono essere preparati.
- I casi di test devono essere eseguiti e controllati per qualsiasi bug presente.
- Se non c’è nessun bug e i casi di test sono passati allora il progetto può essere messo in firma e mandato in produzione.
- Se si trova qualche difetto o bug allora deve essere corretto immediatamente per preparare il rilascio.
Tipi di test UAT
- Alpha e Beta testing: Il test alfa è fatto nel sito di sviluppo mentre il test beta è fatto nell’ambiente esterno, cioè una società esterna ecc.
- Test di accettazione del contratto: In un contratto le specifiche accettate che sono predefinite devono essere soddisfatte.
- Test di accettazione del regolamento: Come dice il nome, il test viene fatto rispetto ai regolamenti.
- Test di accettazione operativa: Il funzionamento o il flusso di lavoro progettato deve essere come previsto.
- Black Box Testing: Senza andare in profondità il software deve essere testato per il suo scopo vitale.
Differenze chiave tra SIT e UAT
| SIT | UAT |
|---|---|
| Questo viene eseguito da tester e sviluppatori. | Questo viene eseguito dagli utenti finali e dai clienti. |
| L’integrazione delle sottounità/unità viene controllata qui. Le interfacce devono essere testate. | L’intero progetto è controllato qui. |
| Le singole unità sono integrate e testate in modo che il sistema funzioni secondo i requisiti. | Il sistema è testato nel suo insieme per la funzionalità principale del prodotto come desiderato dall’utente. |
| È fatto in base ai requisiti dai tester. | E’ fatto in base alla prospettiva dell’utente su come il prodotto deve essere usato dall’utente finale. |
| SIT viene eseguito non appena il sistema viene assemblato. | UAT viene eseguito infine appena prima del rilascio del prodotto. |
Conclusione
Il test di integrazione del sistema è fatto principalmente per testare i requisiti di interfaccia di un sistema. Mentre il test di accettazione dell’utente è fatto per verificare la funzionalità del sistema nel suo complesso da parte di un utente finale. I casi di test appropriati devono essere scritti per entrambi i test.
Il SIT può essere fatto con 3 tecniche (approcci Top-down, Bottom-up e Big bang). UAT può essere fatto usando 5 metodologie (Alpha e Beta testing, Contract Acceptance testing, Regulation Acceptance testing, Operational Acceptance testing, e Black box testing).
I difetti trovati nel test del sistema possono essere corretti facilmente. Diverse build possono essere fatte in base ai difetti. Mentre i difetti trovati in UAT sono considerati come un marchio nero per i tester e non sono accettati.
In UAT i funzionari aziendali o i clienti devono essere soddisfatti che il prodotto sviluppato soddisfi i loro bisogni nell’ambiente aziendale. Il SIT deve soddisfare i requisiti funzionali del sistema.
Speriamo che questo articolo abbia chiarito tutte le vostre domande sul SIT Vs UAT!