Acceptance testing: cos'è e come farlo prima del rilascio

Hai commissionato lo sviluppo di un'app o una piattaforma. Il team di sviluppo ti dice che è pronta. Ma come fai a sapere che funziona davvero come ti aspettavi? È qui che entra in gioco l'acceptance testing: la fase in cui sei tu — o i tuoi utenti reali — a verificare che il software soddisfi i requisiti concordati, prima di accettarlo formalmente e mettere mano al saldo finale.

Molti imprenditori saltano questa fase o la delegano completamente al fornitore. È un errore che spesso si paga caro, in tempo perso, funzionalità sbagliate e rinegoziazioni infinite.

Cos'è l'acceptance testing

L'acceptance testing (o test di accettazione) è il processo di verifica finale che stabilisce se un software è pronto per essere consegnato e messo in produzione. A differenza dei test tecnici — che verificano il codice dall'interno — il test di accettazione guarda il prodotto dal punto di vista dell'utente finale o del committente.

In pratica: esegui una serie di scenari reali sul software e controlli che si comporti come dovrebbe. Se supera tutti i criteri definiti, il software viene accettato. Se no, si torna al fornitore con una lista precisa di problemi.

Esistono due varianti principali:

• UAT (User Acceptance Testing): eseguito dagli utenti finali o da un gruppo rappresentativo. È la forma più comune in progetti B2B e enterprise.
• BAT (Business Acceptance Testing): eseguito dal committente per verificare che i requisiti di business siano soddisfatti, indipendentemente da come sono stati implementati tecnicamente.

Perché è essenziale — e perché viene spesso ignorato

Il test di accettazione è l'unico momento in cui il committente ha pieno controllo prima di firmare la ricezione del lavoro. Eppure viene ignorato per due motivi: la pressione del tempo e la falsa sicurezza dei test tecnici del fornitore.

Il problema è che i test tecnici (unit test, integration test) verificano che il codice funzioni. Non verificano che il software faccia quello che avevi in mente quando hai firmato il contratto. Queste sono due cose diverse.

Esempi concreti di cosa può andare storto senza un acceptance test strutturato:

• Il flusso di checkout funziona tecnicamente, ma la notifica email di conferma non arriva mai
• Il report che hai chiesto genera i dati giusti, ma in un formato illeggibile su mobile
• Il sistema di permessi permette a tutti gli utenti di accedere a dati riservati
• L'integrazione con il CRM importa i contatti ma duplica ogni record

Nessuno di questi bug è banale da scoprire senza testare gli scenari reali.

Come si fa l'acceptance testing: la guida pratica

Ecco come strutturare un processo di test di accettazione efficace, anche se non sei un tecnico.

1. Definisci i criteri di accettazione prima di iniziare lo sviluppo

I criteri di accettazione sono la lista di condizioni che il software deve soddisfare per essere considerato completato. Vanno scritti prima che il codice venga scritto, non a posteriori.

Ogni funzionalità dovrebbe avere almeno un criterio di accettazione nella forma: "Dato [contesto], quando [azione], allora [risultato atteso]."

Esempio: "Dato un utente registrato, quando clicca su 'Recupera password', allora riceve un'email entro 2 minuti con un link valido per 24 ore."

Se stai lavorando con user stories, i criteri di accettazione sono la loro naturale estensione. Se il tuo fornitore non li produce automaticamente, chiedili esplicitamente.

2. Crea un piano di test strutturato

Un piano di test di accettazione non deve essere complicato. Ti basta un foglio (anche Excel) con queste colonne:

• ID scenario: numerazione progressiva
• Funzionalità testata: es. "Login con Google"
• Passi da seguire: sequenza esatta di azioni
• Risultato atteso: cosa deve succedere
• Risultato effettivo: cosa è successo davvero
• Esito: Pass / Fail
• Note: screenshot, comportamento anomalo, ecc.

Non serve testare ogni singolo clic. Concentrati sui flussi critici: registrazione, accesso, pagamento, generazione report, invio dati, notifiche.

3. Coinvolgi gli utenti reali (o persone simili)

Il vantaggio dell'UAT è proprio che chi testa il software non è il team che lo ha sviluppato. L'ideale è coinvolgere chi userà davvero il prodotto: un commerciale, un operatore del magazzino, un responsabile HR — dipende dall'applicativo.

Se stai valutando l'acceptance testing per il tuo progetto, possiamo aiutarti a strutturarlo fin dalla fase di analisi dei requisiti: contattaci dalla sidebar per una consulenza gratuita.

Chiedi a queste persone di eseguire i compiti normali che farebbero nel lavoro quotidiano, usando il software per la prima volta. Le loro difficoltà e i loro errori sono informazioni preziose.

4. Documenta tutto — soprattutto i bug

Ogni anomalia va documentata con precisione: cosa stavi facendo, su quale dispositivo, cosa è successo, screenshot o video se possibile. Una segnalazione vaga come "il sistema non funziona" non aiuta nessuno. Una segnalazione come "su Chrome 124, cliccando su 'Salva bozza' dopo aver allegato un file PDF, la pagina si blocca senza messaggi di errore" è actionable.

Usa un sistema di ticketing anche semplice (Notion, Trello, un Google Sheet condiviso) per tracciare ogni issue e il suo stato di risoluzione.

5. Definisci i criteri di go/no-go

Non tutti i bug hanno lo stesso peso. Prima di iniziare il test, definisci:

• Bug bloccanti: il software non può andare in produzione finché non sono risolti (es. impossibilità di completare un pagamento)
• Bug critici: riducono significativamente l'usabilità ma hanno workaround temporanei
• Bug minori: problemi estetici o di dettaglio che possono essere risolti post-lancio

Il rilascio avviene solo quando tutti i bug bloccanti sono chiusi. Questo criterio va concordato con il fornitore nel contratto, non a voce.

Errori comuni da evitare

Fare l'acceptance test troppo tardi. Se lo fai solo la settimana prima del go-live, non hai tempo di correggere i problemi seri. Pianifica sessioni di UAT in anticipo, specialmente per i flussi principali.

Delegarlo completamente al fornitore. Il fornitore fa i propri test, ma l'acceptance testing è responsabilità del committente. Nessuno conosce il business meglio di te.

Non avere criteri scritti. Senza criteri di accettazione definiti, ogni discussione su cosa "funziona" diventa soggettiva. I criteri scritti proteggono sia te che il fornitore.

Testare solo il caso ottimale. Il software funziona quando tutto va bene. Testa anche i casi limite: cosa succede se l'utente inserisce un dato errato? Se carica un file troppo grande? Se perde la connessione a metà operazione?

Non tracciare i bug formalmente. Un bug segnalato a voce in una telefonata può sparire. Tutto deve essere scritto, assegnato e monitorato fino alla risoluzione.

Checklist rapida per il tuo acceptance test

1. I criteri di accettazione sono stati definiti e condivisi col fornitore prima dello sviluppo?
2. Hai un piano di test con scenari reali dei flussi critici?
3. Hai coinvolto utenti rappresentativi (non solo il team IT interno)?
4. Hai un sistema per documentare e tracciare i bug trovati?
5. Hai definito quali bug sono bloccanti per il rilascio?
6. Hai pianificato almeno due sessioni di UAT: una a metà sviluppo e una pre-lancio?
7. Il contratto con il fornitore prevede un periodo di garanzia post-accettazione?

Quando coinvolgere una software house nell'acceptance testing

Se stai sviluppando un prodotto con una software house esterna, il modo migliore di gestire l'acceptance testing è definirlo nel contratto come milestone formale: il pagamento della tranche finale avviene solo dopo il superamento dei test di accettazione.

Un buon partner tecnologico dovrebbe aiutarti a scrivere i criteri di accettazione, mettere a disposizione un ambiente di staging per i test, e fornire supporto durante le sessioni UAT. Se il tuo fornitore ti dice che non è necessario o che "tanto funziona tutto" — è un segnale da non ignorare.

Hai bisogno di strutturare il collaudo del tuo software o vuoi capire come impostare i criteri di accettazione fin dall'inizio del progetto? Scrivici: trovi il form di contatto qui a destra.