Test di Accettazione Accettabili

Adattato/tradotto da Agile in a Flash

I test di accettazione sono usati per verificare se il team ha costruito quello che il cliente ha chiesto in una 'storia'.

Valgono le seguenti cose:
1) Sono definite dal cliente (attenzione che il cliente in XP non è "chi paga", ma è chi userà l'applicazione, il cliente in XP è responsabile delle funzionalità del prodotto)
2) Definisco cosa vuol dire "done-done" (davvero finito) per le storie
3) Sono automatizzati
4) Documentano l'uso del sistema
5) Non è che coprono solo l'happy path
6) Non sono un rimpiazzo per il test esplorativo
7) Sono eseguiti in un ambiente simile alla produzione

Vediamole nel dettaglio:
1) Sono definiti dal cliente.
I test di accettazione sono un espressione del bisogni del cliente.
Tutti possono contribuire, ma alla fine, una singola voce del cliente definisce i propri interessi come un insieme di test non ambiguo.

2) Definiscono cosa vuol dire "davvero finito" (done-done) per le storie
I test di accettazione sono scritti prima dello sviluppo come se ne fossero un contratto (capitolato?) per il completamento.
I test accettazione che passano dicono ai programmatori che il loro lavoro è finito e dicono ai clienti che essi possono accettarlo.

3) Sono automatizzati
Puoi scrivere descrivere precisamente tutti i passi, e quindi automatizzare, tutti i test che definiscono le capacità del sistema (system capabilities). Script eseguiti manualmente sono una forma di maltrattamento (abuse).

4) Non si limitano agli happy paths
È difficile cogliere tutti i percorsi alternativi e eccezionali. Inevitabilmente ne mancherai qualcuno. Aggiungilo alla tua suite di AT.

5) Non sostituiscono il test esplorativo
Il test explorativo individua la parte più creativa di come un utente potrebbe decidere di interagire con una nuova feature. Inoltre aiuta ad insegnare ai tester come migliorare le loro competenze di progettazione dei test.

6) Si eseguono in un ambiente vicino alla produzione
Gli AT si eseguono in un ambiente che emula la produzione nel modo più fedele possibile. Essi colpiscono database il più possibile veri e API esterne. Gli AT sono per definizione lenti.
l' originale è in questo "libro" https://pragprog.com/titles/olag/agile-in-a-flash

Grazie a Andrea Francia per l'articolo