Cos'è lo user acceptance testing? L'ultimo controllo prima che qualcuno ci faccia affidamento

Lo user acceptance testing è il punto in cui le persone che useranno davvero il software decidono se fa il loro lavoro. Non se funziona - quello è già stato testato - ma se fa la cosa che avevano chiesto, in un modo con cui possono convivere.

È l’unica fase di test il cui scopo è una decisione anziché un elenco di difetti. Lo UAT si chiude con qualcuno che dice sì o no a un rilascio.

Cosa lo distingue da ogni altro test

Ogni fase precedente chiede se il software corrisponde alla sua specifica. Lo UAT chiede se la specifica era giusta.

Questa distinzione sembra accademica finché non la si vede accadere. Una funzionalità può superare ogni test funzionale, soddisfare ogni criterio di accettazione così come è scritto, ed essere comunque respinta in UAT perché la persona che fa quel lavoro trecento volte a settimana vede che le costerà quattro clic dove il vecchio modo ne chiedeva uno. Non è rotto niente. Era sbagliato il requisito, e questo è l’ultimo momento economico per scoprirlo.

Test di QA

Il software fa quello che avevamo detto? Eseguiti dai tester, contro la specifica

User acceptance testing

Fa quello che serve al business? Eseguito da chi quel lavoro lo fa, contro la realtà

Chi lo esegue, e chi non dovrebbe

Le persone che lo useranno. Non il team di sviluppo, non il QA, e non un responsabile che fa le loro veci.

È più difficile di come si legge. Le persone che vuoi sono occupate a fare il lavoro per cui il software esiste, e il loro tempo è la parte più costosa di tutto l’esercizio. Ed è per questo che uno UAT pianificato all’ultimo finisce delegato a chi è libero, e un rilascio viene poi approvato da qualcuno che quel lavoro non l’ha mai fatto.

Due ruoli che vale la pena nominare: qualcuno a cui appartiene la decisione e che può dire di no, e qualcuno che raccoglie ciò che i tester trovano e lo trasforma in qualcosa su cui uno sviluppatore possa lavorare. Senza il primo, lo UAT produce opinioni e nessun esito. Senza il secondo, produce un foglio di calcolo con cui non ci fa niente nessuno.

Cosa va dato ai tester

Non un elenco di funzionalità. Un elenco delle cose che fanno di solito.

1. Portare un cliente nuovo dalla richiesta alla prima fattura
2. Gestire un rimborso per un ordine pagato con carta
3. Chiudere il mese con due filiali che rendicontano separatamente
4. Correggere un indirizzo su un ordine già spedito

Questi sono processi di business, e ognuno attraversa più funzionalità. Un tester a cui dici “controlla la schermata delle fatture” controllerà la schermata delle fatture; un tester a cui dici “porta un cliente nuovo alla sua prima fattura” troverà i due punti in cui il processo si rompe tra una schermata e l’altra, ed è lì che vivono i problemi veri.

Dai loro dati veri, o la copia sicura più vicina. Uno UAT su un database di Cliente di Prova 1 fino a 20 non trova nessuno dei problemi che un cliente di nome “O’Brien & Sons (già Smith)” trova subito.

Quando è finito

Prima che cominci, mettetevi d’accordo su cosa significa “sì”. Per iscritto, e in termini che qualcuno possa verificare.

• Quali processi devono funzionare, e quali possono essere scomodi
• Cosa conta come bloccante, rispetto a cosa si sistema nel rilascio successivo
• Chi firma, e per cosa sta firmando
• Quanto dura. Uno UAT senza data di fine non finisce; sfuma

Il fallimento più comune non è un test sbagliato, è un traguardo poco chiaro. Una fase che dura finché le persone smettono di segnalare cose finisce quando si annoiano, e un rilascio che parte per noia è un rilascio che nessuno ha approvato.

Le segnalazioni che lo UAT produce

Questa è la parte per cui i team di sviluppo si preparano, e il motivo è strutturale più che colpa di qualcuno.

I vostri tester non sono tester. Sono contabili, addetti alla logistica, infermieri, commerciali - e descrivono quello che è successo nella lingua del loro mestiere anziché in quella del software. “La fattura è andata alla filiale sbagliata” è una frase perfettamente chiara e non è riproducibile. Le mancano quale fattura, quale filiale, cosa c’era a schermo e cosa si aspettavano invece.

Due cose aiutano più di qualsiasi altra:

Chiedi il procedimento, non la diagnosi. “Cosa stavi facendo, e cosa ti aspettavi che succedesse?” porta più lontano di qualsiasi modulo, perché l’ipotesi di un utente di business sulla causa è di solito sbagliata e di solito prende il posto dei fatti.

Togli loro di mano la parte tecnica. A nessuno in UAT andrebbe chiesta una versione del browser, un log della console o dei passi scritti per uno sviluppatore. Farlo bene è il compito degli strumenti, e meno chiedi a un tester più quello segnalerà.

Chi raccoglie le segnalazioni deve comunque trasformarne ognuna in qualcosa su cui uno sviluppatore possa lavorare, e la guida alla segnalazione dei bug è la forma che questo prende. Se una scoperta fatta in UAT non si riesce a riprodurre, verrà chiusa irrisolta per quanto reale fosse.

In breve

Lo UAT chiede se il software fa il lavoro, e lo decidono le persone di cui quel lavoro è. Dategli processi anziché schermate, dati veri anziché righe di prova, una definizione concordata di sì, e meno compiti tecnici che potete. Quello che torna indietro sarà espresso nella loro lingua, e trasformarlo in qualcosa di riproducibile è il lavoro, non il segno che hanno testato male.