Unleashing Agile Testing under medical regulations – #AVV2020
Luca Sturaro è un agile coach e trainer appassionato di agilità dal 2011.
Nel suo talk tenuto all’Agile Venture Vimercate 2020, partendo da una esperienza reale in R&D, dopo aver presentato i preconcetti sulla convivenza tra Agilità e norme in ambito medicale, Luca mostra i vincoli e alcune delle sfide affrontate in ambito testing (automation e manuale) per mantenere aderenza agli standard di qualità.
Partendo da una citazione di William Edwards Deming (1)
The quality of a product is directly related to the quality of the process used to create it
La qualità del prodotto è direttamente collegata alla qualità del processo usato per svilupparlo.
Per un prodotto software, quali sono gli standard? Cosa sono gli standard?
Per rispondere alla domanda, Luca riprende la metafora della ricetta del budino, pensata nel lontano 1994 da S. L. Pfleeger, N. Fenton, and N. Page in “Evaluating software engineering standards”:
The recipe, the utensils, and the cooking techniques, and then assume that the pudding will taste good.
Più di vent’anni fa ci si era resi conto che l’occhio era al processo e non al prodotto.
L’Agile Manifesto (2) parla, tra gli altri, di
Individuals and interactions over processes and tools
Working software over comprehensive documentation
In ambiente medicale, fortemente normato, la documentazione è parte del prodotto, inoltre il QMS (Quality Management System) definisce il processo che ha bisogno di essere documentato. Non esiste il prodotto senza documentazione.
L’Agilità come può sopravvivere?
Luca ha preso come esempio uno scenario di un progetto di un’applicazione medica al quale ha preso parte.
Sicuramente bisogna cercare di eliminare le barriere tra i silos che si occupano di qualità e gli altri, includendo i QM (Quality manager) nelle cerimonie come ad esempio i daily stand-up e lavorando assieme al team di quality per fare “tailoring” del QMS su ogni release del software per eliminare la documentazione non necessaria.
Cosa possiamo fare a livello tecnico per essere più agili e quindi permettere anche all’organizzazione di esserlo?
Adottando Git per il versionamento del codice, e armonizzando i vari repository che all’epoca erano multipli.
Pensare ad un single command build, ovvero uno script che esegue una build completa includendo tutti i vari moduli e non una build per ogni modulo per poi dover fare una sorta di collage. Si guadagna tempo, sopratutto per gli sviluppatori. Questo porta a velocizzare il processo e ad avere anche più build giornaliere.
Automatizzare tutti le suite di test, quindi test automation, e implementare test non sono di unità ma anche:
- Sanity Check: eseguire una lista di test minima per capire se una build è ok. Ad esempio, testare che tutti i moduli comunichino tra loro.
- Smoke test della durata di 30 minuti/1 ora
Più test si eseguono, e più aumenta la confidenza sul prodotto per lo sviluppatore. Inoltre si hanno più feedback e più frequentemente. L’obiettivo è cercare di automatizzare l’evidenza oggettiva della verifica, fornendo per ogni step di ogni test log e screenshot.
Conclusioni
Quali sono le lezioni apprese da Luca?
- Fidarsi del team.
- Includere “quality” nel team.
- Evitare silos di R&D.
- Allarghiamo la “definition of done”: facciamo più revisioni di uno stesso documento. Richiede maggiore sforza ma è un approccio incrementale quindi va bene.
- Armonizzare repository e automatizzare la build.
- Iniziare a fare test automatici
- Fare tailoring su QMS per il software, dove possibile
Per ulteriori approfondimenti sul talk, le slide sono disponibili online (3).