Per chi non conoscesse il BDD, un articolo che merita di essere letto credo sia questo. E0' un viaggoi molto interessante nelle motivazioni che hanno portato allo sviluppo di queste tecniche.
Partiamo dal presupposto che un progetto che preveda sin dalla nascita con unit test, funcional test ecc ecc ecc è sicuramente un progetto soldo ed affidabile. Magari fallimentare - aggiungo io - ma di sicuro solido.
Sul perchè fallimentare è inutile dilungarsi troppo... è una questione di principi e punti di vista.
Come su un ring: In un angolo c'è chi crede che si possa, a "tempo 0" identificare tutte le possibili opzioni e comportamenti del sistema, nell'altro chi pensa che cosa fa un sistema lo si potrà scoprire solo quando lo sviluppo sarà terminato.. e lo sviluppo non terminerà MAI!
Eccessi a parte, occorre capire l'utilità (in ogni singolo contesto) dei test per poter capire quale è l'approccio più corretto:
- è uno sviluppo modulare, magari con tante risorse, ed è necessario capire impatti delle singole modifiche,fare regression test, verificare periodicamente la stabilità del sistema?
- è uno sviluppo "one man show", dove si rischia di passare settimane per quello stupendo effetto che fa scomparire il box che decideremo di eliminare in un secondo momento?
- è uno sviluppo "a perdere", magari per fare delle prove o sperimentare delle alternative in modo prototipale?
Eccetra ... eccetra .... eccetra
Insomma ogni progetto ha delle sue caratteristiche, ma ce ne sono alcune che sono comuni a tutti:
- il sistema dovrà avere delle funzionalità - fare delle "cose"
- queste funzionalità ci sono non perchè sono "fiche", ma perchè hanno un valore per il "cliente"
Il DBB si focalizza su questi due punti. Richiede che le funzionalità siano descritte attraverso delle storie che identificano il Come, il Cosa ed il Perchè:
As a Role
I request a Feature
To gain a Benefitovvero
Come RUOLO
Voglio che il sistema FACCIA QUESTO
Per ottenere un VALORE / OBIETTIVO
Anche se sembra una banalità, costringere il cliente ( o noi stessi) ad associare ad ogni funzione un valore costringe a valutare attentamente
- se quella funzionalità davvero serve
- se quella funzionalità può essere fatta in modo diverso
ATTENZIONE!!! Questo non vuol dire che devono essere descritti tutti i pulsanti , finestre, campi, azioni ecc ecc ecc del sistema. Ci si focalizza sulle funzioni ritenute importanti e di valore, e pian piano si aggiungono o modificano.
Ma su questo punto ci torneremo, anche con un post dedicato a come applicare il DBB a progetti già in corso...
Un esempio - preso dal sito di cucumber - descrive come alcune funzioni banali possano o meno essere associate ad un preciso valore di business, parla della funzione di Login.
a che serve il login? o meglio: Che VALORE ha il login?
In effetti se in un certo stato del progetto non siamo in grado di trovare un valore alla funzione di "login", allora non vale la pena svilupparla (in quel momento)
Ma andando ad analizzare meglio la cosa, si può dire che il login server
- perchè ogni utente sia in grado di vedere i suoi ordini così da poterli inviare e far generare profitti
- perchè ogni utente possa personalizzare il suo ambente, così da fidelizzarsi, tornare spesso e permettere una maggiore impression di pubblicità
- perchè il sistema sia in grado di identificare li interessi dell'utente e proporre i giusti suggerimenti e link a prodotti / pubblicità
Se avessimo pensato ad un sistema che non deve tenere traccia di queste funzioni, il login, sebbene possa essere sempre utile per fornire servizi aggiuntivi, non sarebbe stato così indispensabile da identificare subito un suo scenario.
Un altro aspetto interessante del DBB è che, descrivendo i comportamenti, permette di far evolvere i progetti in funzione delle reali necessità, e di far emergere richieste in contrasto con le linee strategiche dell'applicazione (quante volte è capitato di ricevere delle richieste che non avevano senso?)
L'inserimento di un nuovo comportamento non dovrebbe portare problemi agli altri. Il condizionale è d'obbligo perché a volte nuovi comportamenti causano degli effetti "collaterali" ed in tal caso è fondamentale capire se l'effetto è giusto - e quindi occorre rivedere la definizione dei comportamenti - o se c'è un errore nel come il sistema risponde.
Facciamo un esempio.
Stiamo sviluppando un sito con elenchi di prodotti e navigazioni avanzate, ma poichè non facciamo vendita online non è prevista una funzione di login. I nostri scenari quindi non prevedono un "ruolo" dell'utente
In un secondo momento si decide di attivare un "e-commerce" e la relativa funzione di login. I precedenti scenari vanno in errore perché l'autenticazione è stata sviluppata prevedendo un login obbligatorio, e pertanto l'utente "guest" non riesce più a vedere i cataloghi
La presenza dell'errore deve necessariamente essere discussa con il cliente, perché è necessario capire se il vecchio comportamento è valido e mantiene inalterato il suo valore di business (magari il cliente vorrebbe che gli ospiti potessero vedere solo i prodotti e non più i prezzi)
Fin qui la teoria... vedremo successivamente alcune regole su come scrivere le "storie" e su come prdisporre i programmi di controllo
Nessun commento:
Posta un commento