A Quick Guide to Implementing ATDD

Questo articolo fornisce una guida rapida a chiunque sia interessato ad implementare ATDD nei propri team e progetti. Delinea i benefici di seguire questo approccio Agile basato sulla mia esperienza diretta in un team di sviluppo software aziendale.

La collaborazione è uno dei valori fondamentali della metodologia Agile. Una volta, mentre lavoravo ad un grande progetto, ho notato una mancanza di collaborazione tra gli sviluppatori, i tester e gli individui che si occupano di business; una mancanza di chiarezza nei requisiti; un frequente scope-creep dei requisiti; una mancanza di visibilità riguardo ai test completati; e difetti identificati tardi nel ciclo di vita del progetto. La cosa più importante per me, però, era che nessuno aveva idea del nostro framework di automazione, quindi tutti i test di automazione venivano scritti dopo che le caratteristiche erano state sviluppate e pronte per il test. A causa di queste osservazioni, ho iniziato a ricercare come le persone affrontano questo tipo di problemi. Come risultato, ho trovato Acceptance Test Driven Development (ATDD) come uno degli approcci utilizzati per mitigare molti di questi problemi. È spesso usato come sinonimo di Behavior Driven Development (BDD), Story Test Driven Development (SDD) e Specification By Example (SBE). La principale distinzione di ATDD, rispetto ad altri approcci agili, è il suo focus sul far collaborare sviluppatori, tester, uomini d’affari, proprietari di prodotti e altri stakeholder come una sola unità e creare una chiara comprensione di ciò che deve essere implementato.

Sulla base della mia esperienza personale, condividerò le mie idee su come i team possono implementare ATDD nei loro progetti.

Il contesto

Ho lavorato in una grande azienda che aveva una mentalità da startup, quindi qualsiasi idea innovativa e feedback era incoraggiata dal team. Abbiamo costruito rapidamente dei prototipi per vedere se un’idea avrebbe migliorato il nostro prodotto o se avrebbe aiutato gli obiettivi generali dell’azienda. Ero il capo tester in un team di 25 membri, che consisteva in uno scrum master, un capo tecnico e diversi analisti di business, designer, sviluppatori e tester. Come risultato della cultura dell’innovazione, c’era spesso il caos all’interno del team, compresi frequenti cambiamenti nei requisiti delle caratteristiche, individui che lavoravano in ambienti siloed, e il morale del team era al minimo storico. Questo era preoccupante per me, così mi sono offerto volontario per aiutare a trovare una risoluzione a questi punti dolenti, il che mi ha portato all’ATDD.

Tutti i miei apprendimenti e la mia esperienza con l’ATDD possono essere categorizzati nei seguenti 3 passi.

Il ciclo di implementazione di ATDD

Creato da Raj Subramanian

Fase 1 – Formazione e sperimentazione

Ci sono molti modi di approcciare i compiti, specialmente quando si considerano le esperienze individuali che lavorano in diversi team agili dentro e fuori le loro attuali organizzazioni. Per portare una comprensione condivisa e comune degli obiettivi del team e dell’organizzazione, è importante fornire la formazione adeguata. Per quanto riguarda ATDD nello specifico, dovrebbe includere gli obiettivi, le aspettative e le informazioni sui risultati che verranno dall’uso di questo approccio. Dopo la formazione, è importante iniziare con un’implementazione su piccola scala per provare cose diverse e ricevere un feedback iterativo.

Per esempio, dopo aver fatto ricerche sull’ATDD, ho spiegato ai diversi stakeholder perché avevamo bisogno di esplorare questo approccio e quali benefici avremmo ricevuto da esso. Ho evidenziato alcuni dei possibili vantaggi come una maggiore collaborazione del team, una migliore chiarificazione dei requisiti, una più precoce identificazione dei difetti all’interno del ciclo di vita dello sviluppo del software (SDLC), una maggiore visibilità e un uso più precoce dell’automazione nell’SDLC, così come il coinvolgimento dell’intero team nell’elaborazione di chiari criteri di accettazione.

Durante la mia discussione con gli stakeholder, ho sottolineato che questo avrebbe richiesto una certa sperimentazione, ma senza provarlo, non avremmo mai potuto conoscerne i benefici. Dopo alcune lunghe discussioni, abbiamo deciso di dividere il team originale di 25 persone in 2 team più piccoli: Il team A era composto da 12 persone e avrebbe implementato ATDD. Il Team B aveva le rimanenti 13 persone, e avrebbe continuato a fare quello che stava già facendo.

Ho pianificato un workshop di formazione di 2 giorni per il Team A imparando su ATDD, determinando quali concetti avevano senso nel contesto del nostro progetto, e come avremmo potuto sfruttare l’automazione durante questo processo. Ho incluso una miscela di esercizi teorici e pratici nella formazione. Alcuni degli esercizi sono qui sotto:

• Come scrivere dichiarazioni Gherkin – Given/When/Then (GWT)
• Quali sono gli attributi chiave di una buona user story?
• Una dimostrazione del nostro framework di automazione, incluso come funzionava e come era strutturato. Ci sono stati anche esercizi su come scrivere semplice codice di test di automazione come una squadra. Prima del workshop, un membro del team ed io abbiamo modificato il nostro framework di automazione per essere in sintonia con l’approccio ATDD. Abbiamo usato il plugin Cucumber con Java e Appium per il nostro framework di automazione.

Source

Step 2 – Increasing Visibility

Quando un progetto vive attraverso più sprint, è facile perdere traccia dei diversi processi che devono essere seguiti. Quindi la chiave è rendere gli scopi, gli obiettivi e le aspettative visibili a tutto il team.

Quando abbiamo iniziato ad usare l’ATDD, ho iniziato semplicemente scrivendo ognuno dei processi giornalieri che avrebbero dovuto essere seguiti su una lavagna bianca, che ho messo dove il nostro team aveva le sue riunioni quotidiane di stand-up. Su ogni storia utente ho aggiunto una lista di controllo degli elementi che dovevano essere fatti prima che la storia fosse considerata completa. In questo modo non c’era ambiguità su quali processi ATDD dovevano essere seguiti. Uno di questi elementi della lista di controllo era un incontro di kick-off, durante il quale lo sviluppatore, il tester e la gente del business discutevano i requisiti come una squadra, identificavano quali requisiti potevano essere automatizzati e delineavano i criteri di accettazione della storia in formato GWT. Un altro elemento della lista di controllo era il QA-Dev Handoff, dove lo sviluppatore mostrava al tester, tramite una rapida dimostrazione o discussione, come i requisiti erano stati completati e quali test unitari erano stati scritti come parte della storia. Attraverso questo handoff, il tester imparava quali aree non erano coperte dai test unitari e sviluppava una migliore comprensione della caratteristica implementata, portando quindi ad una migliore copertura dei test. Le voci della lista di controllo erano a volte ovvie, ma è bene averle chiaramente dichiarate. Ne abbiamo incluso uno per assicurare che tutti i difetti associati alla storia fossero chiusi; un altro era l’approvazione finale da parte di una persona del business dopo aver visto una demo, assicurando che la caratteristica fosse costruita secondo i requisiti e le aspettative precedentemente stabilite.

Abbiamo anche iniziato ad avere un “Process Hawk”. Questo era un singolo membro del team; poteva essere uno scrum master, un project manager o chiunque assicurasse che il team seguisse il processo. Nel mio caso, era un altro tester senior all’interno del team; lui ed io ricordavamo regolarmente a tutti di seguire il processo ATDD in tutte le riunioni, incluso lo standup, la pianificazione, la retrospettiva e altre riunioni del team.

Step 3- Apprendimento iterativo e feedback

Avere un costante ciclo di feedback è cruciale nell’implementazione di qualsiasi approccio agile, incluso ATDD. Avere incontri settimanali o bisettimanali di retrospettiva con tutto il team è un modo importante per sapere quali parti del processo stanno effettivamente portando beneficio al team, e quali potrebbero aver bisogno di essere modificate. Come già sappiamo, qualcosa che non aiuta il team porta a sprecare tempo e fatica. Come afferma Brian Tracy, autore di Eat That Frog: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time, “Uno dei peggiori usi del tempo è fare molto bene qualcosa che non deve essere fatto affatto.”

Nell’attuale era della tecnologia informatica, le organizzazioni non possono permettersi di sprecare tempo ed energia in approcci inefficaci; piuttosto, abbiamo bisogno di processi snelli ed efficaci. Questo si collega al principio di lean startup di Validated Learning: il ciclo Build, Measure, Learn.

Con questo in mente, ho iniziato a fare incontri di 30 minuti ogni giovedì con il team A per controllare come il team sta facendo con il nuovo processo. Questo era un buon modo per valutare quali cambiamenti dovevano essere fatti in base alle reazioni del team. Questo incontro avveniva separatamente dall’incontro retrospettivo che era alla fine degli sprint di 2 settimane. Questo approccio ha portato un feedback continuo dal team, permettendoci di fare cambiamenti immediati ed efficaci. Il feedback non proveniva solo dai check-in settimanali del processo; anche le riunioni quotidiane di stand-up hanno dimostrato di essere una fonte preziosa di informazioni. Gli aggiornamenti e le discussioni dei singoli membri del team hanno fatto emergere le bandiere rosse relative al processo, e siamo stati in grado di affrontarle immediatamente prima che influenzassero il resto del team.

Sommario

Come risultato del seguire il ciclo di implementazione di ATDD, il Team A ha iniziato a vedere notevoli differenze nel morale del team, nella collaborazione e nei requisiti.

Morale del team

Tutti hanno iniziato a lavorare come una squadra e si sono sentiti responsabilizzati. Ogni persona possedeva una storia dall’inizio alla fine. Si è assicurato che la storia avesse tutte le informazioni necessarie per iniziare il lavoro di sviluppo e di test. Il membro del team si assicurava anche che tutti i follow up relativi alla storia fossero fatti. Infine, la persona era incaricata di dimostrare la storia a tutti gli stakeholder alla fine dello sprint. Questa sensazione di proprietà ha aumentato significativamente il morale del team.

Collaborazione

Le riunioni di kick-off hanno portato la persona di business, lo sviluppatore e il tester insieme, al fine di sviluppare una comprensione comune della storia utente. Il QA-Dev Handoff, che è avvenuto prima di spingere la build ai server QA, ha aiutato sia lo sviluppatore che il tester a sapere quali test sarebbero stati completati come parte della storia, e ha portato una migliore comprensione della caratteristica implementata. C’è stata una maggiore visibilità nell’automazione, dal momento che l’intero team ha preso la proprietà, invece che solo i tester. Infine, nelle riunioni di pianificazione, l’intero team ha discusso la storia insieme, generando così più idee, domande e discussioni. L’aumento della collaborazione ha portato anche ad un aumento dell’apprendimento – il team ha deciso di avere sessioni di coaching peer-to-peer per imparare gli uni dagli altri, i tester hanno iniziato a fare test esplorativi in coppia e sessioni di lunch-n-learn sono state ospitate da diversi membri del team per discutere di vari argomenti riguardanti la tecnologia. Tutte queste cose hanno portato a migliorare la collaborazione generale del team.

Requisiti

Uno dei problemi principali con i nostri processi precedenti erano i frequenti cambiamenti nei requisiti e lo scorrimento della portata. Con l’approccio ATDD, era imperativo che una volta che lo sviluppatore iniziava a lavorare su una storia, i requisiti venivano bloccati. Qualsiasi cambiamento doveva essere messo in ordine di priorità insieme alle altre storie in arrivo e aggiunto ai prossimi sprint. Questo ha ridotto il carico di lavoro sia degli sviluppatori che dei tester, e ha impedito agli stakeholder di avere aspettative irrealistiche sulle caratteristiche completate.

Dopo aver visto tutti i miglioramenti di cui sopra il Team B ha iniziato ad implementare anche l’ATDD. Come risultato, l’intero team originale ha usato questo approccio dopo una regolare sperimentazione e feedback.

Conclusione

Consiglio l’approccio di ATDD, e si allinea con il “Paradigma dello spostamento a sinistra” che afferma che lo sviluppo e i test dovrebbero iniziare il più presto possibile nell’SDLC. Ha portato più visibilità nell’automazione perché abbiamo iniziato a scrivere test automatici all’inizio dell’SDLC, che a sua volta ha aumentato la collaborazione all’interno del team.

Fonte

Ricorda, ATDD non è una soluzione “one size fits all”. Era l’approccio agile che aveva più senso nel contesto del mio progetto, ma ci sono vari altri modi per migliorare i processi nei team. Ho usato questo approccio per l’attenzione ai migliori test di accettazione, ma soprattutto per la sua enfasi sulla collaborazione. La parte della collaborazione è parte integrante di questo approccio, e credo che sia la più preziosa.

Informazioni sull’autore

Raj Subrameyer è un tech career strategist che si concentra sull’aiutare le persone a trovare il lavoro dei loro sogni e a diventare leader di successo. È appassionato nel guidare i professionisti a massimizzare le loro opportunità e scoprire la loro zona di genio. Usa la sua esperienza nell’industria tecnologica per ricercare, parlare e scrivere su come possiamo abbracciare la tecnologia e diventare cittadini digitali a pieno titolo. È uno speaker ricercato in varie conferenze ed è stato citato in numerosi podcast e pubblicazioni, tra cui CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success e The Good Men Project. È anche l’autore del nuovo libro “Skyrocket Your Career”. Le sue aree di competenza includono avanzamento di carriera, leadership, motivazione, produttività e imprenditorialità. Nel suo tempo libero, ama viaggiare e godersi la birra artigianale. Potete trovare maggiori informazioni su come serve le persone attraverso il suo sito web.