Se avete familiarità con TDD allora ATDD è in qualche modo TDD con un livello più alto di test e con più stakeholder coinvolti, in altre parole è più un test di accettazione che un test unitario. Se vuoi saperne di più su TDD allora controlla il seguente post:
Acceptance test-driven development (ATDD) è una metodologia di sviluppo basata sulla comunicazione tra i clienti aziendali, gli sviluppatori e i tester. ATDD comprende molte delle stesse pratiche come la specificazione per esempio, lo sviluppo guidato dal comportamento (BDD), lo sviluppo guidato dall’esempio (EDD), e lo sviluppo guidato dal supporto chiamato anche sviluppo guidato dalla storia (SDD). Tutti questi processi aiutano gli sviluppatori e i tester a capire i bisogni del cliente prima dell’implementazione e permettono ai clienti di essere in grado di conversare nel loro linguaggio di dominio.
Ampiamente implementato nei team Agile, ATDD è una pratica in cui analisti di business, sviluppatori, tester e utenti lavorano insieme per definire ogni storia (o caratteristica) criteri di accettazione in una fase iniziale del processo di sviluppo (prima che inizi la codifica). Questo approccio permette a tutte le parti interessate di avere e mantenere lo stesso livello di risultati attesi prima che qualsiasi sviluppatore inizi a codificare.
So che tutti abbiamo sentito questo stereotipo “Gli sviluppatori non si preoccupano delle specifiche e i tester non vogliono fare automazione” ma con ATDD questo farà risparmiare un sacco di tempo e denaro sprecato assicurando che gli sviluppatori siano più coinvolti nelle prime fasi delle specifiche e i tester stiano automatizzando i test di accettazione.
Come viene implementato ATDD nella “vita reale”?
Stai usando SCRUM? Se sì, allora stai già facendo la maggior parte del lavoro in ATDD. Se no, il seguente esempio deve alimentare la tua curiosità :
Esempio
Immaginiamo che il proprietario del prodotto o il cliente abbia richiesto la seguente caratteristica nella nostra applicazione mobile: “Come utente voglio bypassare la schermata di login in modo da poter utilizzare l’applicazione in modo anonimo” Dopo aver esaminato questa richiesta con tutto il team (Business analyst, sviluppatori, tester…) e con ulteriori dettagli aggiunti alla storia o alla caratteristica, avremo alcuni test di “accettazione” o “funzionali” simili a questo (Si prega di notare che questo è solo un esempio, molti test di accettazione mancano per questa caratteristica):
- Criteri di accettazione 1: L’applicazione accetta opzionalmente login/password per il login
- Criteri di accettazione 2: Il bypass del pulsante permette all’utente di navigare all’interno dell’applicazione senza login.
- Criteri di accettazione 3: Quando il pulsante di bypass selezionato l’applicazione non memorizza o visualizza alcuna informazione specifica dell’utente.
- Criteri di accettazione 4: Quando il login/password sono utilizzati, l’interfaccia grafica dell’applicazione deve essere adattata alle impostazioni dell’utente.
Benefici
1- Allineamento cliente-venditore: avendo i criteri di accettazione di cui sopra come informazioni di input, noi (ogni membro del team) siamo ora sicuri che l’applicazione manterrà la sua funzionalità di login/password e aggiungerà solo un pulsante per permettere all’utente di bypassare la schermata di login.
2- Qualità ed efficacia dei costi: I test di cui sopra possono essere facilmente automatizzati anche prima che gli sviluppatori inizino a codificare.
3- Time to Market: Una volta che i test sono implementati gli sviluppatori possono convalidare i loro compiti richiesti prima di annunciare che hanno finito.
ATDD non richiede strumenti specifici. È importante sapere che NON tutti i test di accettazione devono essere automatizzati. Automatizzare i tuoi test dipende da molteplici aspetti come: sfide tecniche, scadenza e costi.
Qualsiasi strumento raccomandato?
ATDD non richiede strumenti specifici. È importante sapere che NON tutti i test di accettazione devono essere automatizzati. L’automazione dei test dipende da molteplici aspetti come: sfide tecniche, scadenze e costi.
In questa sezione vi darò solo una panoramica degli strumenti di automazione più usati su ATDD:
FitNess: Il wiki standalone completamente integrato e il framework per i test di accettazione
Robot framework: framework generico di automazione dei test per i test di accettazione e lo sviluppo guidato dai test di accettazione (ATDD)
Calabash: Test di accettazione automatizzati per applicazioni mobili – Siate consapevoli che questo framework potrebbe non supportare l’ultima versione del sistema operativo (sopra Android O)
.