Un team una volta fornisce un sistema di spesa che supera tutti i test tecnici. Il primo giorno, il team finanziario scopre di non essere in grado di gestire sinistri multivaluta, che costituiscono gran parte del loro lavoro. Non c’era nulla di “rotto”, ma non era utilizzabile. I test di accettazione da parte degli utenti esistono per individuare esattamente questo tipo di lacuna prima del lancio.

Questa guida spiega in che modo UAT differisce da altri test, come eseguirlo passo dopo passo e come decidere quando sei pronto per il rilascio. Lo scenario riportato sopra e gli esempi riportati di seguito sono illustrativi e il processo dovrebbe essere adattato al tuo progetto.

Cos’è l’UAT?

L’UAT è solitamente la fase di test finale prima del rilascio, in cui gli utenti previsti confermano che il software può svolgere il proprio lavoro in condizioni realistiche. Viene anche chiamato test dell’utente finale o test di accettazione. Viene dopo lo sviluppo e il test del sistema, quando ci si aspetta che il prodotto sia stabile.

Il suo scopo non è trovare tutti i bug. A questo punto, la maggior parte di questi dovrebbe già essere sparita. Lo scopo è la validazione: abbiamo costruito la cosa giusta? I tester verificano che il prodotto corrisponda alle specifiche. L’UAT verifica che le specifiche e il prodotto soddisfino effettivamente l’esigenza.

Test UAT e QA

L’UAT non sostituisce altri test. Se gli utenti continuano a riscontrare bug di base, la build non era pronta e stai sprecando il loro tempo limitato. Questi problemi appartengono ai livelli di test precedenti e ai test di regressione.

Chi gestisce l’UAT?

Scegli i tester che svolgono davvero il lavoro oggi. Un gestore esperto dei sinistri individuerà i problemi che un manager o un delegato non vedrebbero mai. Includere una vasta gamma di esperienze, perché un nuovo dipendente spesso rivela passaggi confusi che un esperto aggira senza accorgersene. E assicurati che i loro manager abbiano tempo a disposizione per questo, poiché l’UAT non può avere successo con un carico di lavoro completo.

Tipi di UAT

Il processo UAT in sette fasi

1. Definire ambito e obiettivi

Decidi cosa viene accettato, cosa non rientra nell’ambito e quali risultati aziendali contano. Ad esempio: “Il personale finanziario può inviare, approvare e pagare una richiesta di spesa, in qualsiasi valuta supportata.”

2. Concordare i criteri di accettazione

Scrivi in un linguaggio semplice come si presenta il successo, idealmente all’inizio del progetto piuttosto che una settimana prima del lancio. Criteri vaghi portano poi a discussioni.

3. Scegli e istruisci i tester

Seleziona gli utenti reali, spiega lo scopo, mostra loro come registrare il feedback e chiarisci che stanno testando il software anziché essere testati da soli. Molte persone temono di sbagliare qualcosa.

4. Preparare l’ambiente e i dati

L’ambiente UAT dovrebbe assomigliare alla produzione il più fedelmente possibile. Utilizza dati realistici, imposta i ruoli utente corretti e controlla le integrazioni come la posta elettronica. Se copi i dati di produzione, maschera prima le informazioni personali. Esegui un rapido test del fumo, in modo che i tester non arrivino e trovino una build rotta.

5. Scrivi scenari

Basateli su flussi di lavoro reali piuttosto che su singoli pulsanti. Dovrebbero essere letti come il lavoro, non come il software. La nostra guida al caso di test e scenario di test spiega quanti dettagli ti servono.

6. Esegui i test e raccogli feedback

Esegui sessioni con qualcuno disponibile ad aiutarti. Raccogli i problemi in un unico posto, con screenshot. Lascia anche un po’ di tempo per l’esplorazione libera, poiché le persone provano cose che gli script non prevedono mai. I test esplorativi offrono tecniche utili a questo scopo.

7. Correggere, ripetere il test e approvare

Valuta il feedback, risolvi ciò che conta e chiedi agli stessi utenti di confermare le correzioni. Quindi registrare una decisione formale.

Un caso di prova UAT

Un caso di test UAT dovrebbe essere facile da seguire per qualcuno non tecnico. Ecco un esempio di sistema di spesa:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Tieni presente che descrive un compito reale, non dettagli tecnici, e che lascia spazio a commenti. Questi commenti spesso si rivelano la parte più preziosa, come “funziona, ma non troverei mai quel pulsante”.

Criteri di entrata e di uscita

Questi si inseriscono nel più ampio ciclo di vita dei test del software. Stabilisci in anticipo i numeri con i tuoi stakeholder. “Decideremo quando lo riterremo opportuno” tende a portare a un sì affrettato, spinto dalla scadenza.

Gestire il feedback

Il feedback UAT è un misto di cose e non tutto è un bug. Ordinalo in categorie:

Utilizza regole chiare per ciò che blocca un rilascio, come descritto in gravità e priorità. E rispondi a ogni articolo, compresi quelli che rifiuti. Le persone smettono di dare feedback se sembra scomparire. La nostra guida su come scrivere una segnalazione di bug può aiutare i tester a descrivere chiaramente i problemi.

Lista di controllo UAT

Prima dell’UAT

• La portata e i criteri di accettazione vengono concordati per iscritto
• I test di sistema e di regressione sono terminati
• I tester vengono scelti, informati e hanno tempo
• Ambiente, conti e dati realistici sono pronti
• I dati personali nelle copie sono stati mascherati
• Gli scenari vengono esaminati dall’azienda
• È impostato un luogo in cui registrare i problemi
• Viene nominato il proprietario dell’autorizzazione

Durante l’UAT

• È disponibile un contatto di supporto
• I problemi vengono valutati ogni giorno
• I progressi sono condivisi con le parti interessate
• Le correzioni vengono implementate e testate nuovamente in modo controllato

Dopo l’UAT

• I criteri di uscita sono stati controllati
• I problemi noti sono documentati con i proprietari
• Viene registrata la firma formale
• Le note sulla formazione e sulla versione vengono aggiornate
• Si è tenuta una breve retrospettiva

UAT nei team Agile

L’UAT tradizionale si presenta come una grande fase finale, in cui una sorpresa è costosa. I team agili accorciano questo ciclo. I proprietari del prodotto esaminano ogni storia rispetto ai criteri di accettazione durante lo sprint e gli utenti vedono il software funzionante durante le revisioni dello sprint. Molti team eseguono ancora una UAT mirata prima di una versione importante, in particolare quando diverse funzionalità si combinano in un unico flusso di lavoro.

Con rilasci frequenti, tecniche come i flag di funzionalità e le distribuzioni canary consentono agli utenti reali di provare gradualmente il nuovo lavoro. Si noti che questi completano i test di accettazione, ma non li sostituiscono automaticamente, soprattutto nei settori regolamentati che necessitano di una registrazione formale.

Errori comuni

• Trattandolo come una formalità. Un’approvazione senza utilità reale non protegge nessuno.
• Utilizzare i tester sbagliati. Gli sviluppatori e il QA hanno troppa conoscenza del sistema per rappresentare gli utenti.
• Iniziare con una build instabile. I tester perdono fiducia e interesse rapidamente.
• Lasciarlo fino all’ultimo minuto. Quindi non c’è tempo per correggere ciò che impari.
• Utilizzo di dati non realistici. I dati dei test raramente presentano i casi disordinati tipici del lavoro reale.
• Lasciare che la portata cresca. Tratta le nuove idee come richieste di modifica, a meno che non siano veri e propri ostacoli.

Considerazioni finali

L’UAT è la tua ultima possibilità per sapere, prima del rilascio, se il software aiuta davvero le persone che lo utilizzeranno. Pianificalo dall’inizio di un progetto, recluta utenti reali e concorda come sarà il successo. Per la tua prossima versione, prova un semplice cambiamento: siediti con un utente durante uno scenario reale e non dire nulla mentre lavora.

Domande frequenti

Continua a imparare