TDD, BDD, ATDD: la ricerca della qualità del software aziendale e della produttività degli sviluppatori prevede che i team trovino nuovi metodi per svolgere il proprio lavoro. Le organizzazioni che seguono logiche di sviluppo Agile versatili e iterativi, stanno utilizzando tecniche che garantiscono maggior valore rispetto a un approccio lineare e sequenziale a cascata.
TDD, BDD, ATDD: significato e finalità
Prima di tutto riassumiamo un po’ di glossario della programmazione:
- TDD e ATDD: la programmazione guidata dai test (Test-Driven Development) e le sue varianti come, ad esempio, lo sviluppo guidato dai test di accettazione (ATDD – Acceptance Test-Driven Development), aiutano ad accorciare il ciclo dello sviluppo.
- BDD: la programmazione guidata dal comportamento (Behavior-Driven Development) enfatizza i requisiti.
- SBE: le specifiche per esempio (Specification By Example) obbligano i team di sviluppo a comprendere meglio l’utente del software.
- SDD: lo sviluppo guidato dal supporto (Support-Driven Development) valorizza l’intero ciclo di vita applicativo.
TDD, BDD, ATDD così come altre tecniche di sviluppo software Agile influiscono sia sugli sviluppatori che sugli stakeholder dell’app. Non si tratta di scegliere l’uno a l’altra: a seconda delle necessità si possono scegliere diversi approcci a livello di organizzazione.
TDD: le cose da sapere
Scrivere e testare il codice per soddisfare i requisiti delle iterazioni Agile è difficile e richiede tempo. Rimane poi sempre il rischio che una suite di test non sia in grado di valutare i comportamenti del software o si perda per strada il comportamento.
Il TDD è una tecnica di programmazione che accelera lo sviluppo e il test del software. I team implementano cicli di sviluppo estremamente brevi con casi di test semplici e diretti. Ad esempio, se il software deve eseguire un determinato calcolo, lo sviluppatore utilizza il TDD per identificare e testare la formula rispetto a una serie nota di dati di input e output. Il processo TDD consente ai team di identificare prima di tutto gli obiettivi del codice, sotto forma di test. Gli sviluppatori si concentrano unicamente sul completamento del lavoro necessario a raggiungere questi obiettivi: al di fuori di questo ambito, non viene eseguita alcun altro tipo di codifica. In questo modo, il TDD riduce gli sforzi al minimo.
Per eseguire lo sviluppo basato sui test, è necessario:
- identificare un comportamento, un output o un risultato per il software
- preparare un test specifico per valutare il risultato desiderato.
- aggiungere o modificare il codice quando l’iterazione del software non supera il test
- ripulire o riformattare il codice al termine del test per garantire leggibilità e manutenibilità.
- rieseguire i test per verificare che il lavoro di pulizia non interrompa inavvertitamente la app
Vantaggi del TDD
I vantaggi del TDD per gli sviluppatori sono diversi. Dal momento che i test vengono scritti prima di aggiungere o modificare il codice, viene garantita una migliore comprensione dei requisiti software. Inoltre, gli sviluppatori scrivono codice per verificabilità ma la portata dello sviluppo è limitata. Ogni caratteristica o funzione scritta, per altro, viene testata, migliorando così la qualità del codice.
Svantaggi del TDD
Uno dei punti critici del TDD è che gli sviluppatori non sono tester addestrati. Quando gli sviluppatori scrivono prima i test, errori od omissioni si riflettono nel codice. Il consiglio degli esperti è di verificare i test rispetto ai requisiti, promuovendo il coinvolgimento del team, per impedire agli sviluppatori di trascurare aree di test critiche. Il TDD, per altro, potrebbe non essere appropriato quando le iterazioni richiedono test ampi, come nel caso di test funzionali completi.
Dato il suo ambito relativamente ristretto e la sua natura granulare, il TDD funziona meglio su piccole unità di lavoro, aiutando anche i team a mantenere il codice legacy quando sono necessarie piccole modifiche specifiche.
ATDD: le cose da sapere
Alcune organizzazioni preferiscono utilizzare l’ATDD rispetto al TDD. Il cambio è di prospettiva: da un punto di vista incentrato sulle funzionalità se ne sceglie uno incentrato sulle esigenze aziendali e le aspettative degli utenti. Rispetto al TDD, dunque, l’ATDD modifica il paradigma di sviluppo, enfatizzando la collaborazione tra business leader, utenti e il team di sviluppo.
I test di accettazione assicurano che il software soddisfi i requisiti aziendali e dei clienti. L’ATDD combina test di collaudo con test granulari per risultati di sviluppo specifici e focalizzati sull’utente.
Attraverso l’ATDD, gli sviluppatori valutano tutto ciò che l’utente potrebbe sperimentare. Un esempio sono i cambiamenti di stato nel sistema di immissione degli ordini di un’azienda da ricevuti a spediti a pagati. L’ATDD, per altro, può verificare in che modo il software interagisce con altre piattaforme o sistemi, come servizi Web o database.
Dal punto di vista del processo, l’ATDD è praticamente identico al TDD. Uno sviluppatore scrive un test per valutare un particolare requisito o comportamento. Quando l’iterazione del software non supera il test, lo sviluppatore aggiunge o modifica il codice e potrebbe anche eseguirne il debug per produrre il risultato desiderato.
TDD e ATDD: quali sono le differenze
La principale differenza tra ATDD e TDD è il linguaggio utilizzato nella creazione del test. I test ATDD sono facilmente leggibili dagli esseri umani, usando termini business o incentrati sull’utente in un formato convenzionale, come now / if / then, al contrario del focus sulla funzionalità tipico di TDD. Mentre le descrizioni sono semplici e dirette, il codice effettivo potrebbe essere complesso. Un’istruzione ATDD di esempio riporta: Dato lo stato di un sistema, se si verifica un’azione o un evento specifico, lo stato cambierà in un modo particolare.
Ogni requisito ha un test corrispondente in ATDD. I requisiti senza test o non sono stati implementati correttamente o non sono proprio stati implementati. I test senza requisiti non sono necessari. Tuttavia, i risultati dei test ATDD possono generare ulteriori domande o problemi che portano a successive modifiche e a ulteriori test. Pertanto, l’ATDD può essere parte integrante dell’evoluzione e della maturità di un progetto.
Una cosa importante da sapere è che l’ATDD non può essere utilizzato da solo, ma fa parte di una suite di test generale. Gli ingegneri addetti al controllo qualità dovrebbero applicare altre tecniche, come test di usabilità e test di sicurezza, per convalidare il rilascio completo.
BDD: le cose da sapere
Il BDD è un’altra tecnica di sviluppo Agile. Analogamente a quanto avviene in un processo TDD, lo sviluppatore definisce un test, lo osserva fallire nella versione del codice corrente, e va a implementare le modifiche per ottenere un risultato positivo. La differenza tra TDD e BDD è che i test BDD si concentrano sui comportamenti del software, ovvero su come gli sviluppatori e le parti interessate ritengono che il software dovrebbe funzionare. Pertanto, i team di sviluppo specificano i test BDD in termini di comportamento del software e valore commerciale relativo.
Il BDD si basa sulle specifiche di test di ATDD per creare un approccio più dettagliato e conversazionale finalizzato a delineare i comportamenti del software. Le specifiche BDD in genere iniziano con un titolo, seguito da un breve descrizione che evidenzia:
- l’utente del software
- il comportamento desiderato del software
- il vantaggio offerto dal comportamento
Le specifiche BDD includono criteri di accettazione che stabiliscono lo stato iniziale, gli eventi, i trigger e i risultati previsti: sostanzialmente è un test ATDD all’interno del test BDD. Le specifiche potrebbero includere percorsi multipli, scenari o condizionali che dettano comportamenti o risultati diversi.
I team di sviluppo concepiscono e creano test BDD all’inizio dell’iterazione, quindi collaborano con i proprietari dei prodotti per identificare comportamenti mancanti o errati, prima di codificare ed eseguire i test. La natura a mano libera di TDD e ATDD non presta facilmente a quei paradigmi di sviluppo degli strumenti. Al contrario, BDD pone una forte enfasi sui formati linguistici, il che significa che gli strumenti possono analizzare ed elaborare i requisiti comportamentali per produrre test eseguibili. Frame come JBehave, rbehave e CBehave leggono e analizzano le parole chiave nei documenti delle specifiche, quindi traducono ogni clausola in parametri per il test.
SBE: le cose da sapere
È difficile stabilire requisiti e test per software complessi. In alcuni approcci di sviluppo, infatti, dichiarazioni astratte comportano ambiguità o requisiti incompleti. Per utilizzare l’SBE, i proprietari dei prodotti, gli sviluppatori e i tester collaborano per descrivere e comprendere i comportamenti del software attraverso esempi realistici, allo stesso modo di quanto avviene con l’ATDD.
L’SBE è una tecnica utile negli schemi di sviluppo Agile caratterizzata da brevi cicli iterativi. Le organizzazioni lo utilizzano per formulare requisiti e test funzionali su progetti grandi e complessi, con esempi concordati prima della programmazione.
Gli aspetti principali di SBE sono:
- Una serie di esempi concreti chiarisce i comportamenti concettuali del progetto software previsto
- I requisiti software creati attraverso la collaborazione formano un’unica risorsa comune condivisa da leader aziendali, sviluppatori e tester
- Il set completo di esempi non solo stabilisce le specifiche del software, ma fornisce anche criteri di test di accettazione incentrati sul business.
- Gli esempi, per altro, costituiscono anche una base per formulare tutta la documentazione che supporta lo sviluppo del prodotto in corso
Il documento sui requisiti SBE elimina varie versioni e prospettive, nonché la necessità di coordinarsi regolarmente tra diverse prospettive. Quando sorgono nuove informazioni o necessità, le organizzazioni adeguano la risorsa.
SDD: le cose da sapere
Creare il software che i clienti desiderano, mantenendolo in modo efficace per tutto il suo ciclo di vita è una bella sfida. In molti casi, le organizzazioni scrivono software utilizzando specifiche e requisiti originati dal team di sviluppo, ma altri team mantengono il codice attivo. L’SDD è una tecnica che cancella questi silos, coinvolgendo gli sviluppatori di software nel supporto continuo del prodotto e nelle operazioni IT.
Quando gli sviluppatori forniscono supporto diretto e ricevono feedback degli utenti, comprendono meglio i problemi del prodotto, ottenendo chiarezza su chi utilizza il software e come. Gli sviluppatori possono utilizzare queste informazioni per implementare future iterazioni del software che soddisfano le richieste degli utenti.
A differenza di altre tecniche di sviluppo software Agile come il TDD e l’BDD, l’SDD deriva i requisiti dal feedback post-release. Il feedback diretto degli utenti offre vantaggi consistenti, permettendo di dare al cliente ciò che desidera veramente: una procedura che si applica bene nell’ambito degli acquisti, dei social media e di altre soluzioni software incentrati sui consumatori. Il feedback degli utenti modella i nuovi requisiti, specifiche e test per le successive iterazioni.
