Confronto fra metodologie
Le metodologie Agile applicate allo sviluppo di servizi e APP sono basate sulla possibilità di effettuare cicli continui di esecuzione di test, più o meno atomici, e dell’interazione con le fasi di debugging e refactoring del codice.
TDD: Test-Driven Development
Il TDD è caratterizzato dalla scrittura di test-case con strumenti e approccio tipici del coding, pertanto risulta indispensabile avere competenze tecniche di sviluppo per la stesura dei test stessi, anche quando i team di test sono organizzati in modo separato dai team di sviluppo. Gli strumenti di scrittura del test sono integrati (o integrabili) nei developer tools e devono rispettare i requisiti della filiera di devops e/o test-automation adottata nel progetto.
E’ cura dello sviluppatore seguire la corretta metodologia di implementazione per garantire la continua consistenza, atomicità e testabilità dei rilasci, attenendosi anche alle direttive per garantire la qualità del software.
La fase di progettazione e scrittura nasce dalla comprensione dei requisiti tecnici di progetto.Per efficientare il processo di sviluppo e di refactor i test-case, oltre che autoconsistenti, devono risultare il più possibile atomici.
Il TDD non garantisce di per sè che il codice implementi esattamente I requisiti funzioinali della soluzione: adottarlo garantisce solo che il codice sia coperto da test e che i test vengano superati.
BDD: Behavioral Driven Development
BDD è un approccio di sviluppo in cui vengono definiti i comportamenti previsti prima di eseguire qualsiasi altra attività di sviluppo o test. (TEST FIRST)
I «comportamenti» attesi della soluzione sono più dei requisiti funzionali stessi. La fase di design del test può essere suddivisa in un fase di descrizione del comportamento e in una successiva fase di maggior dettaglio in cui vengono individuati tutti i singoli passi che compongono l’intero scenario.In questo modo è più facile indirizzare uno sviluppo autoconsistente delle singole funzionalità e suddividere in parti più semplici la soluzione da implementare e le conseguenti fasi di testing.
L’analista descrive in modo semplice e diretto:
- Given => il contesto iniziale
- When => il verificarsi di uno specifico evento
- Then => l’output atteso
Il BDD Tool esegue gli scenari ed il tester raccoglie esiti raffrontabili con il comportamento funzionale atteso. Il vantaggio è che gli strumenti per disegnare gli scenari di test sono del tutto indipendenti dalla tecnologia che verrà utilizzata per l’implementazione e risultano utilizzabili anche da figure professionali non dedicate allo sviluppo di codice, ma capaci di interpretare un requisito funzionale o di business.
Il coding a supporto del testing in questo modello si concentra sulla stesura del glue-code, cioè a collegare le chiamate delle funzionalità più semplici necessarie ad implementare il comportamento atteso.
I tools BDD analizzano i file delle caratteristiche ed eseguono il glue-code appropriato associando i comportamenti alle fasi di esecuzione in un motore di test specifico. Di conseguenza, i tester possono utilizzare i feature files come casi di test funzionali più semplici che verificano i comportamenti associati ai requisiti di business.
ATDD: Acceptance Test Driven Development
La tecnica ATDD si può considerare un’estensione del BDD che si pone dal punto di vista dell’utente finale ed è quindi focalizzata a verificare se il codice implementa I requisiti di business attesi, cioè se la soluzione si comporta esattamente come l’utente si aspetta.
”Is the code working as expected?”
ATDD si concentra sulla raccolta dei requisiti affinando il processo di validazione verso l’utente finale e verso lo sviluppo snellendo le fasi di progettazione e focalizzando il testing.
Favorisce la collaborazione dei vari gruppi coinvolti nell’intero processo di progettazione, sviluppo, testing e vendita di una soluzione software facilitando da una parte il design e dall’altra verificando via via la fattibilità, l’usabilità e la bontà dell’implementazione.