Cosa sono gli User Acceptance Test e come realizzarli

Durante il processo di sviluppo, è fondamentale garantire che il prodotto software risponda alle specifiche funzionali prima del suo rilascio. Che si tratti del lancio di un nuovo sito E-commerce o della validazione di un impianto di automazione logistica, quella degli UAT è una fase del progetto che non può essere trascurata.

Cosa sono gli UAT? Gli UAT (User Acceptance Test) fanno riferimento alla fase di progetto in cui uno sviluppo o configurazione, siano essi su un sistema pacchettizzato o relativi ad un prodotto custom, vengono validati dal team utente come conformi alle specifiche, sia funzionali che in termini di convalida dei dati.

Approfondiamo alcune domande tra le più comuni sul tema degli UAT ascoltando le risposte della nostra Project Manager Senior Lara Dal Monte.

Test UAT: quando è necessario eseguirli

Gli UAT Test si eseguono in tutti i progetti o le attività che prevedono lo sviluppo o aggiornamento di un prodotto in base a dei requisiti definiti dal business.

La fase di UAT viene svolta al termine degli sviluppi e, solitamente, dopo una precedente fase di test tecnici svolti dai provider. Gli UAT vengono svolti in quello che viene definito ambiente di test o di collaudo, ossia un ambiente dove è possibile simulare l’intera funzionalità da testare.

Solo una volta terminati con esito positivo gli UAT sarà possibile portare in ambiente di produzione il prodotto e renderlo effettivamente fruibile ai destinatari finali.

Vuoi conoscere il nostro approccio e come possiamo supportarti?

Come condurre i test UAT

Il processo di UAT si articola nelle seguenti fasi:

Redazione del test plan

Per poter gestire gli UAT deve essere redatto un piano di test che raccolga tutti i casi da testare. Il piano di test solitamente viene redatto a partire dall’analisi funzionale approvata, che è lo stesso documento su cui si basa lo sviluppo tecnico.

Il piano di test contiene uno o più casi di test in cui viene descritta l’azione che l’utente deve effettuare il risultato atteso, ossia come ci aspettiamo che si comporti il sistema in relazione a quell’azione.
Il test plan deve prevedere tutti gli scenari necessari ad accertarsi che quanto previsto nell’analisi funzionale sia stato effettivamente sviluppato secondo i requisiti.

In alcuni casi, il piano di test può prevedere dei casi di test di non regressione che sono volti a verificare che componenti del prodotto impattate dalla modifica ma non direttamente oggetto della modifica, continuino a funzionare correttamente.

Pianificazione dei test

In base ai casi di test previsti nel test plan, è necessario che siano stimati i tempi necessari per l’esecuzione dei test e che siano coinvolti i referenti business necessari. Con questi ultimi andranno concordati tempi e modi per l’esecuzione dei test, andando anche a definire lo strumento / gli strumenti a supporto per l’annotazione degli esiti dei test e per il censimento di eventuali bug.

Solitamente la pianificazione prevede un tempo dedicato al bug fixing (correzione degli errori rilevati da parte del provider) e al re-test (nuovo test della soluzione dopo l’applicazione delle correzioni).

Coordinamento dei test

Nei casi in cui i test sono molto estesi e complessi, solitamente viene previsto un coordinamento delle risorse che eseguono i test in modo da monitorare che i tempi di esecuzione siano in linea con la pianificazione e in modo da sollevare eventuali criticità (ad esempio, nel caso in cui vengano rilevati molti bug).

Bug fixing

Il bug fixing è la fase in cui il provider, raccolte tutte le segnalazioni di bug (o parte di esse) ne prevede la correzione. Uno degli strumenti di cui ci avvaliamo per il tracciamento dei bug UAT è JIRA della suite Atlassian. Per alcuni progetti abbiamo infatti, attraverso JIRA, configurato dei workflow specifici per la gestione degli UAT, in modo da poter controllare con molta precisione il processo di bug reporting e bug fixing.

Re-Test

Fase dedicata al test del prodotto dopo l’applicazione della soluzione ai bug segnalati.

UAT e Integration Test: quali sono le differenze?

Gli User Acceptance Test (UAT) sono test condotti dai referenti business che hanno commissionato il prodotto e che sono propedeutici all’effettivo rilascio agli utilizzatori finali della soluzione.


Gli Integration test sono test tecnici che vengono svolti nel caso in cui la soluzione preveda lo scambio informativo tra sistemi, ossia delle integrazioni. I test di integrazione sono finalizzati a verificare che i sistemi si scambino i dati correttamente secondo le specifiche tecniche definite.
Ad esempio, un test di integrazione può riguardare la verifica degli scambi informativi (sincroni o asincroni) tra l’ERP e la piattaforma eCommerce per la gestione di prodotti, prezzi, stock e ordini.

Gli strumenti che utilizziamo per la realizzazione degli UAT

Per la scrittura del test plan può essere utilizzato un foglio Excel con una struttura standard, comune per tutti i test plan realizzati.


Per la pianificazione delle attività di test, molto dipende dagli strumenti utilizzati dal Cliente. Lo stesso test plan potrebbe essere caricato su strumenti specifici che consentono il tracciamento delle attività di test e il collegamento tra test case e bug segnalati (ad esempio, Zephyr – tool di JIRA, qTest). Inoltre potrebbero esserci strumenti specifici per consentire il censimento dei bug e la presa in carico da parte del provider.

E’ chiaro che utilizzare degli strumenti dedicati rende più semplice tutta la fase di coordinamento, anche se resta possibile gestire l’intero processo tramite l’utilizzo di file Excel condivisi.

Hai bisogno di essere supportato nella scrittura ed esecuzione degli UAT?

Quando il test può considerarsi valido?

Il test può considerarsi valido quando è rispettato il risultato atteso definito nel test case.
In caso di censimento di bug, sarà necessario ripetere il test dopo la correzione e verificare il raggiungimento del risultato atteso. E’ possibile che il gruppo di lavoro decida di rilasciare il prodotto agli utilizzatori finali anche in presenza di bug, in caso siano ritenuti non bloccanti.