In questo articolo in cui adottiamo il format dell’ intervista doppia, affronteremo insieme a Tommaso e Lara l’ampio tema degli User Acceptance Test ovvero gli UAT guardandolo da due diverse angolazioni, E-commerce e revisione aziendale da un lato e Supply Chain e Automazione Logistica dall’altro.
Affronteremo il tema sia da un punto di vista gestionale che operativo, individuando elementi pratici che possano essere di aiuto e stimolo ad ulteriori conversazioni sul tema.
In questa pagina:
Chi siete e qual è il vostro ruolo in Gung?
Lara: “ Lavoro in Gung dal 2016 e sono responsabile dei progetti di Digital Transformation; seguo, come Project Manager Senior, progetti di Digital Transformation con particolare focus sull’ implementazione di siti E-commerce e di revisione dei processi aziendali. Durante gli anni in Gung ho seguito diversi corsi, tra cui quelli necessari per conseguire la certificazione PRINCE in Project Management.
Prima di arrivare in Gung ho avuto una breve esperienza nel mondo dell’E-commerce in ruoli operativi.
Come formazione arrivo da un settore del tutto diverso, ho conseguito una laurea triennale in comunicazione pubblica e una magistrale in Marketing e ricerche di mercato all’Università di Pisa.
Tommaso: “Sono il fondatore di Gung, insieme al mio socio Gabriele Ricciardi. Mentre lui si occupa principalmente dei progetti di Data Intelligence io supporto le Direzioni IT dei nostri clienti su progetti complessi e coordino le attività del team sui progetti di Supply Chain e Automazione Logistica.
Mi sono laureato in Matematica all’Università di Firenze e ho seguito diversi corsi di formazione tra cui un corso di specializzazione sulla gestione dei sistemi informativi in SDA Bocconi ed un Master in Supply Chain e Logistica Integrata.”
Approfondisci insieme agli esperti del team come possiamo supportarti in tutto il processo degli UAT
Che cosa si intende per UAT?
Lara: “UAT è l’acronimo di User Acceptance Test. Gli UAT sono una delle fasi più impegnative di un progetto in quanto gli utenti business, avendo a disposizione un ambiente di prova, verificano che il prodotto consegnato risponda ai requisiti definiti nelle analisi preliminari all’implementazione.
Solitamente la fase di UAT segue quella dedicata ai test tecnici o SIT (System Integration Test), in cui gli sviluppatori verificano il corretto funzionamento del software implementato e delle eventuali integrazioni con altri sistemi.
Solo nel momento in cui la fase di UAT viene conclusa il prodotto può essere considerato validato e pronto per il rilascio in produzione. Ad esempio, nel caso del lancio sul mercato di un nuovo sito E-commerce i test da eseguire saranno volti a garantire che all’apertura del sito tutto funzioni correttamente e che l’esperienza di navigazione e di acquisto del cliente sia quella attesa.”
Tommaso: “Si tratta dei test di accettazione utente. In sostanza, si tratta della la fase in cui uno sviluppo o configurazione, siano essi su un sistema pacchettizzato o relativi ad un prodotto custom, vengono verificati dal team utente come conformi alle specifiche, sia funzionali che in termini di convalida dei dati.
Gli UAT si caratterizzano poi in diversi modi a seconda del contesto in cui si svolgono. Ad esempio, gli UAT di un sistema di fatturazione elettronica sono condotti maniera totalmente diversa dagli UAT di un sistema di Business Intelligence o dalla validazione che si può dare ad un impianto di Automazione Logistica. Restano però capisaldi il metodo generale, l’approccio asettico che si deve usare e la separazione delle responsabilità nell’esecuzione degli UAT tra chi li esegue e valida e chi li supporta (in genere un PM del team sviluppo o un PM di progetto).”
Qual è il processo che si segue nella realizzazione degli UAT?
Lara: “Per poter avviare la fase di UAT è necessario che sia stato definito il test plan completo di tutti i test case necessari alla validazione del prodotto. Chi redige il test plan deve conoscere approfonditamente i requisiti funzionali che sono stati concordati con gli utenti business in modo da includere casi di test adatti a verificare il corretto funzionamento di tutti i processi previsti.
Ad esempio, il test della pagina prodotto di un E-commerce dovrà prevedere la verifica di tutte le informazioni anagrafiche previste (nome del prodotto, descrizioni, immagini, ecc..), della composizione grafica della pagina, della gestione dei prezzi standard e promozionali, e così via.”
Tommaso: “La realizzazione degli UAT parte innanzitutto dalla loro pianificazione, definendo il tempo e le risorse necessarie. La determinazione delle tempistiche è influenzata dalla metodologia di gestione del progetto – waterfall/agile/ibrida. Nella nostra esperienza con le aziende frequentemente rileviamo che il tempo previsto per questa fase è appena sufficiente in quanto, nella maggior parte dei casi, non si tiene conto del processo di rework, spesso necessario a seguito della rilevazione di non conformità.
Dalla pianificazione in poi il processo seguito nella fase operativa è quello descritto da Lara, che comincia con la revisione dei requisiti e la costruzione del test plan con i test case sulla base di questi.
Da non sottovalutare nell’esecuzione dei test anche la possibilità, e direi la necessità, di eseguire test liberi. Si tratta di test condotti fuori dallo schema previsto dall’ambito dei test case, per cui spesso vale l’esperienza dell’utente e la conoscenza dell’ambito funzionale applicativo.”
Qual è il processo di costruzione dei test plan e dei test case?
Lara: “Il test plan sarà costituito da diverse sezioni, ognuna delle quali conterrà uno o più test case. Ogni sezione del test plan corrisponde generalmente a una parte del processo definito.
Ad esempio, il test plan di un sito E-commerce dovrà prevedere, a grandi linee, le sezioni riguardanti:
- homepage
- pagina prodotto
- carrello
- checkout
- pagine editoriali
- login e area personale.
Per ogni sezione del test plan saranno definiti i diversi test case in base, come già accennato, ai requisiti funzionali condivisi e approvati dagli utenti business.”
Tommaso: “Nella fase di redazione dei test plan e test case sono importanti, oltre che la definizione dei passi del test le due sezioni che riguardano i dati (o le categorie/tipologie di dati) da usare nella fase esecutiva del test e una descrizione sufficientemente precisa del risultato atteso, che consente all’utente di validare il test.
Ad ogni test case va associato un identificativo univoco per la successiva fase di bug reporting e sarebbe bene assegnare una rilevanza (ad esempio un caso di test relativo ai pagamenti E-commerce ha una rilevanza maggiore rispetto ad un caso di test relativo alla gestione di un reso). In casi più complessi è consigliabile spacchettare il test case in step atomici che consentono un pieno controllo delle singole azioni. La granularità dipende dal tipo di test, dalla rilevanza del caso e dalla sua complessità.”
Hai bisogno di un supporto per la gestione dei Test in ambito E-commerce o nel mondo logistico
Quali strumenti usate per la redazione dei test plan e dei test case?
Lara: “La prima stesura del test plan e dei test case avviene solitamente su un file Excel. Successivamente, i casi di test previsti vengono trasferiti su uno strumento definito dal Cliente che permette di monitorare il progress dell’esecuzione dei test. Alcuni esempi di strumenti che mi è capitato di utilizzare per gli UAT sono JIRA Zephyr, un add on che è possibile aggiungere a JIRA per il tracciamento dei test, oppure qTest.”
Tommaso: “Negli anni il principe della redazione dei test case è ancora Excel. Ma ci sono sempre più strumenti che, partendo dalla raccolta e definizione dei requisiti, consentono una rapida definizione dei test case e la loro mappatura sul requisito specifico.
Come strumenti specifici abbiamo aiutato nostri clienti ad usare diversi strumenti. Molto interessante è qTest, di Tricentis, che abbiamo usato in maniera un po’ semplificata rispetto alle grandi potenzialità dello strumento. In altri casi abbiamo appunto usato Zephyr, come add on di JIRA. Come al solito lo strumento è un elemento di efficientamento del processo e questo vale anche negli UAT. La parte fondamentale resta la corretta pianificazione e la costruzione di test plan efficaci e completi.”
Come registrate l’esecuzione dei test e quali strumenti di reporting usate per condividere i risultati del test con gli utenti?
Lara: “In genere, soprattutto in caso di test plan articolati, si preferisce utilizzare uno strumento che permetta di tracciare il progress dei test. Una volta inserito il test plan, completo di tutti i test case, gli utenti business potranno tracciare l’esito dei singoli test case: in progress, in fase di esecuzione, OK se il test ha avuto esito positivo o KO se il test ha avuto esito negativo. Tramite questi stessi strumenti è generalmente possibile ottenere delle estrazioni in formato excel per il monitoraggio periodico dello stato dei test.
Nel caso in cui si decida di non utilizzare uno strumento di questo tipo, è comunque possibile utilizzare Excel per tenere traccia del progress dei test. Ovviamente in questo caso l’attività diviene più onerosa e più difficile da coordinare in quanto lo strumento utilizzato non è accessibile da tutti gli attori coinvolti.”
Tommaso: “Come nel caso precedente la scelta degli strumenti di registrazione dell’esecuzione dei test dipende da ciò che i nostri clienti hanno disposizione. Il corretto processo registrazione dell’avanzamento del test avviene più o meno facilmente a seconda della corretta impostazione e configurazione del sistema di test case usato. Alla massima flessibilità di Excel, corrisponde una manualità nella gestione della reportistica di avanzamento. Alla maggiore strutturazione e talvolta apparente rigidità di strumenti dedicati alla gestione degli UAT corrisponde una rapida visibilità dello stato delle attività.
Io personalmente preferisco la seconda strada, ma comprendiamo che l’uso di strumenti dedicati non sempre è percepito come elemento centrale nel processo di UAT.”
JIRA per il tracciamento dei bug nel processo UAT
Lara: “In caso di malfunzionamenti, detti in gergo tecnico “bug”, è necessario che quanto riscontrato venga descritto dettagliatamente e condiviso con gli sviluppatori in modo che sia possibile correggere l’errore.
Anche in questo caso la gestione della fase di progetto giova della scelta di utilizzare uno strumento condiviso e accessibile a tutti gli attori coinvolti in modo da agevolare la condivisione delle informazioni e da velocizzare la presa in carico e risoluzione delle problematiche.
Uno degli strumenti più utilizzati per la gestione dei progetti è JIRA della suite Atlassian.”
Tommaso: “Sicuramente lo strumento più usato negli ultimi anni nei nostri progetti è JIRA. Il tracciamento dei bug in JIRA, può affiancare la gestione degli UAT. Per alcuni progetti abbiamo infatti configurato dei workflow specifici, in modo da poter controllare con molta precisione il processo di bug reporting e bug fixing.
La possibilità di configurare JIRA e personalizzare le “segnalazioni” ( chiamate issue o ticket), rendono lo strumento abbastanza modellabile sulle necessità del vasto “pubblico” che si trova ad interagire con la segnalazione stessa, da colui che registra l’anomalia allo sviluppatore che poi va a correggerla, permettendo anche di ridurre o azzerare i molteplici scambi di mail.
È possibile gestire il Test UAT come vera tipologia di issue personalizzata da tanti campi quanti sono le specifiche del test stesso. Così facendo il classico “file excel” con il test plan, può essere caricato all’interno di JIRA: n. righe del test diventerebbero n. issue da assegnare, compilare, eseguire, e far avanzare in un flusso di lavoro specifico (per esempio il semplice Da fare, In corso, Testo OK/ Test KO).
L’esito negativo o dubbio dell’esecuzione del test viene tracciato collegando, alla issue di test, quella dell’eventuale bug.
JIRA permette, a chiunque abbia accesso alla piattaforma, di aprire segnalazioni di tipo bug riguardanti uno specifico software, una procedura, un esito di un UAT, ecc e di monitorarle fino alla risoluzione in un unico ambiente.
Nei progetti Jira dedicati specificatamente alle fasi di UAT, abbiamo anche creato workflow ulteriori oltre a quello del bug reporting, nello specifico per la gestione di richieste di supporto e per il censimento in fase di UAT di CR connettendo quindi il processo di UAT di un progetto alla successiva fase di Manutenzione Evolutiva.”
Vuoi implementare un workflow per il tracciamento degli UAT su Jira?
Quale ruolo svolge Gung nella fase di UAT?
Lara: “Questo dipende molto dal progetto e dalle richieste del cliente. Solitamente, partecipando alle fasi di analisi, i Clienti trovano utile coinvolgerci nella fase di redazione del test plan e del test case, talvolta in collaborazione con altri fornitori che partecipano al progetto. Il ruolo prevalente, in quanto PM, rimane quello del coordinamento delle attività dei vari attori che partecipano alla fase di UAT (utenti business, sviluppatori).”
Tommaso: “Innanzitutto uno degli obiettivi strategici di Gung è efficientare e digitalizzare tutti i processi aziendali dei nostri clienti. Di conseguenza effettuiamo un continuo monitoraggio di modalità e strumenti che possano rendere più efficace ed efficiente la fase di UAT.
Da un punto di vista operativo poi, come Project Manager e come supporto operativo alle fasi di progetto, il ruolo che giochiamo è quello che descrive Lara, dalla componente di pianificazione dei test fino alla loro parte operativa con l’esecuzione e la registrazione delle anomalie. Dipende pertanto dal progetto e dal cliente. Gung è in grado di supportare tutto il processo.”
Quali sono i criteri di chiusura degli UAT?
Lara: “Nella situazione ideale gli UAT possono considerarsi conclusi una volta che tutti i test case sono stati completati con esito positivo. Questo significa che ogni eventuale malfunzionamento rilevato è stato corretto e testato nuovamente con esito positivo.
Non di rado capita che, per diversi motivi, in caso persistano dei bug giudicati non bloccanti per il passaggio in produzione si decida comunque di procedere nonostante la presenza di casi di test ancora aperti. In questo ultimo caso le correzioni in sospeso dovranno essere applicate successivamente a validazione avvenuta.”
Tommaso: “Ovviamente l’ideale è la chiusura con successo di tutte le anomalie rilevate. Questo costituisce il criterio guida. Nel mondo reale poi proprio grazie alla classificazione della rilevanza del caso di test e di conseguenza anche della gravità dei bug si possono creare matrici di accettabilità che consentono di considerare approvato un passaggio in produzione pur mantenendo la presenza di anomalie che dovranno essere risolte durante una prima fase di GoLive di progetto, spesso identificata come HyperCare.
In questa fase si ha il passaggio dalla modalità di gestione degli UAT come test per l’approvazione dell’intero set funzionale, a casi univoci come se si trattasse di singole CR che verranno raccolte in release di post-produzione. Per questo, l’uso di strumenti per la gestione degli UAT, è molto utile per avviare un controllo molto puntuale anche per l’esecuzione delle fasi successive.”
Hai bisogno di essere supportato nella scrittura ed esecuzione degli UAT?
Differenze tra UAT nella fase di Application Maintanance e sviluppo progetto.
Lara: “In fase di sviluppo progetto i test utente devono riguardare la verifica del processo end-to-end in modo da verificare che il prodotto sviluppato sia adeguato rispetto alle specifiche funzionali.
Generalmente in fase di Application Maintenance vengono gestite delle modifiche a parti del prodotto, quindi i test definiti in questi casi riguardano solo le parti impattate dalla modifica.”
Tommaso: “La differenza principale consiste nella complessità della pianificazione e della costruzione dei test case che si riferiscono ad un set di requisiti generalmente molto ampio.
Poi se il processo di UAT è gestito correttamente, le differenze stanno solo nella più facile organizzazione dei pacchetti di CR che devono essere rilasciati e di conseguenza nell’attribuzione della priorità che deve essere data all’esecuzione dei singoli test case”
Qual è il set completo UAT che suggeriresti al prossimo cliente?
Lara: “L’organizzazione degli UAT dipende molto dal tipo di progetto e dal prodotto sviluppato.
Il suggerimento che mi sento di dare è di non sottovalutare mai la fase di UAT a livello di pianificazione, si tratta di una parte cruciale del progetto e che impegna molto in termini di tempo e risorse.
Gli strumenti che ho apprezzato e utilizzati in progetti a cui ho partecipato sono JIRA Zephyr e qTest.”
Tommaso: “Come detto, la scelta degli strumenti deve essere fatta in conformità di ciò che l’organizzazione del cliente mette a disposizione e della complessità del progetto. Sicuramente l‘uso di uno strumento di catalogazione dell’intero ciclo di requisiti, test plan, test case e il legame che ha con JIRA per l’associazione del bug reporting, configura qTest come lo strumento più completo che ad oggi abbiamo utilizzato. Inoltre consente di pianificare i test assegnandoli alle risorse configurate nello strumento, quindi copre anche la parte più alta del processo di UAT. Anche Zephyr ci ha aiutato, ma ho trovato maggiori benefici nell’uso di qTest anche per la parte di reporting. Imprescindibile per i progetti che abbiamo gestito è l’uso di JIRA come strumento di bug reporting”
Vuoi sapere come lavoriamo nella gestione degli UAT?
Differenze tra UAT nel metodo agile e waterfall.
Lara: “Il metodo waterfall prevede il rilascio del prodotto al termine dello sviluppo completo, in questo caso la pianificazione degli UAT deve necessariamente seguire il termine dello sviluppo tecnico.
Alla fase di UAT seguirà l’analisi e risoluzione dei malfunzionamenti registrati e il re-test prima dell’effettivo rilascio in produzione.
Il metodo agile prevede invece l’organizzazione del lavoro di sviluppo in “sprint”; ossia pacchetti di lavorazione di due/tre settimane al termine delle quali viene rilasciata una porzione di software completamente funzionante. In questo caso gli UAT dovrebbero essere programmati al termine di ogni sprint in modo da verificare le funzionalità specifiche rilasciate e segnalare eventuali malfunzionamenti, che saranno lavorati nel corso degli sviluppi degli sprint successivi.
Questo approccio permette maggiore flessibilità nelle attività tecniche ma, potenzialmente, un maggior lavoro in carico agli utenti per lo svolgimento dei test. Infatti, nonostante siano previsti dei test al termine di ogni sprint suggeriamo sempre di prevedere una fase finale di UAT preventiva al rilascio in produzione”
Tommaso: “Chiaramente, il diverso approccio delle due modalità per la fase di sviluppo, consente di parzializzare il carico di lavoro degli UAT nei singoli sprint. Questo fornisce un vantaggio nella loro organizzazione, prioritizzazione, semplicità e rapidità di esecuzione. Di contro, diventa assolutamente imprescindibile disegnare un processo molto attento di riassegnazione delle anomalie rilevate agli sprint successivi e di costruzione dei set dati di test che può essere difficoltoso o costoso nelle reiterazioni. Il cambiamento e l’adeguamento dei requisiti può inoltre portare al ridisegno di casi di test anche già positivamente superati per le integrazioni successive di specifiche. Questo richiede un allineamento alle pratiche agile di tutta l’organizzazione per non avere la sensazione di dover ritestare tutto da principio.”
Come gestite i tempi degli UAT?
Lara: “Questo aspetto può rivelarsi complesso. Ritengo che gli aspetti fondamentali in fase di preparazione siano:
- Prevedere dei tempi congrui rispetto al piano di test previsto in base a delle stime sui tempi di esecuzione
- Prevedere nella pianificazione il tempo necessario alla nuova esecuzione dei test dopo la correzione dei malfunzionamenti
- Prevedere con anticipo il coinvolgimento di tutte le risorse necessarie, che spesso devono coniugare le attività di test con quelle “ordinarie”
Durante lo svolgimento dei test:
- Assicurare il massimo supporto degli attori tecnici per la pronta risoluzione dei malfunzionamenti segnalati
- Gestire una reportistica di facile lettura sull’avanzamento dell’esecuzione dei test”
Tommaso: “Concordo con Lara. La pianificazione degli UAT, comprendente anche la corretta allocazione di tempo da dedicare alla costruzione dei test plan, è un aspetto che richiede una significativa esperienza sia nel processo di testing sia nello specifico ambito di business e inoltre, una buona conoscenza del team nel suo complesso, in modo da poter indirizzare fin dalla fase di pianificazione le criticità che l’allocazione di un team non esclusivamente dedicato alla fase di testing ha nella interferenza delle attività ordinarie.
Con riferimento a questa ultima indicazione occorrerebbe valutare, in alcune aziende di media/grande complessità, la costruzione di team e professionalità specifiche nell’esecuzione dei test cross funzionali e cross business, cosicché siano sempre più focalizzati nell’ottimizzazione del processo, che conoscano bene la realtà in cui andranno ad operare e che via via sviluppino processi e si avvalgano di strumenti sempre più efficienti.”
Vuoi essere supportato nella pianificazione degli UAT?
Avete mai utilizzato test automatici?
Lara: “Non mi è mai capitato ma mi interesserebbe approfondire questa possibilità”
Tommaso: “Sì, all’inizio della mia carriera, quando ho lavorato in Microsoft nel lontano 1996 come software localiser, avevamo a disposizione uno strumento sviluppato da un collega che ci consentiva di individuare le macro criticità che la traduzione apportava al software ad esempio, dialog box o pulsanti non corretti per l’aumentata dimensione dei testi tradotti oppure, errori causati dalla presenza di caratteri speciali o il non corretto trattamento dei caratteri di escape all’interno del testo. Da allora, ho avuto il modo di interfacciarmi con poche e piccole esperienze di test automation, forse anche dettate dal tipo di progetti che abbiamo supportato negli anni o dovuti forse agli investimenti abbastanza significativi in know-how che questi richiedono.”
Avete mai fatto uso del Crowd Testing?
Lara: “Non mi è mai capitato ma mi interesserebbe approfondire questa possibilità”
Tommaso: “Si, ho lavorato in un caso di test di una App per un cliente di telefonia mobile e l’ho trovato estremamente utile. Le attività di raccolta dei tester e di coordinamento delle loro attività è stato fatto da una società specializzata in crowd testing, ma per il bug reporting ed il bug fixing abbiamo usato il processo definito internamente con il supporto di Jira.
Anche in questo caso, come per la parte di test di automazione, occorre trovare il dominio giusto di applicazione ed una competenza e supporto adeguato. Il mondo delle App e delle applicazioni Web B2C potrebbe trarne molti vantaggi.”