Rischi dell'introdurre un team dedicato al testing

Una decisione strategica che riscontro spesso è l’istituzione di un gruppo di persone (esito a chiamarlo “team”, che ha una connotazione molto precisa e implicazioni notevoli) dedicato alla funzione del testing.

Anche se motivata da buone ragioni è davvero una decisione sensata? Si sono considerate tutte le sue possibili conseguenze negative e modi per contrastarle? Spesso la risposta è “NO”. 

Le motivazioni per istituire un siffatto gruppo (chiamato spesso “Quality Assurance”) sono varie.

Alcune sono legati ad aspetti economici e amministrativi: per uniformità delle attività a cui il gruppo di QA è chiamato a svolgere, è comodo accentrare la formazione dei tester, l’evoluzione di carriera su diversi livelli di specializzazione. Risulta anche più comodo gestire l’organizzazione del lavoro tra le persone, l’approvvigionamento di strumenti adeguati, la co-presenza delle persone in uno o pochi uffici, la disseminazione di buone pratiche ed esperienze. Se tutte queste cose fanno capo a unica unità organizzativa all’interno dell’azienda sarà più facile gestirla, assegnare un budget, monitorarne il funzionamento e l’efficienza, farla evolvere e migliorarla.

L’altra grossa motivazione deriva dall’aspettativa che sia meglio assegnare la funzione di tester a delle persone che non sono direttamente coinvolte nella costruzione di ciò che viene testato. Chiamo questo il principio del “ogni scaraffone è bell’a mamma soja". 

Anche il nome “Quality Assurance” evoca fantasiosamente che questo sia il gruppo che crea la qualità necessaria e che, grazie a qualche magia, la inietta nel sistema che viene sviluppato.

Indipendentemente dalle ragioni, da manager e stratega aziendale però non posso evitare di soppesare le conseguenze negative di tale scelta. E per quelle che sono in grado di immaginare, mi devo chiedere in che modo si possa mitigarne gli effetti negativi.

Tra le conseguenze negative possiamo annoverare quanto segue.

Creando il gruppo di QA creiamo un silo, e come ho discusso altrove, occorre capire quali interazioni e scambi questo nuovo gruppo dovrebbe poter svolgere.

Consideriamo la relazione con il gruppo di sviluppo e con quello di analisi che frequentemente si instaura.

QA prenderà possesso di un nuovo artefatto (un modulo, un componente, un sottosistema, un release candidate di tutto il sistema) rilasciato dal gruppo di sviluppo e svolgerà le procedure di test che riterrà opportune. Al termine, produrrà del feedback che verrà comunicato agli sviluppatori, sottoforma di un rapporto.

Per decidere che procedure di test attuare, QA avrà interagito con gli analisti e progettisti, i quali avranno avuto modo di far loro avere una formulazione scritta di requisiti e specifiche tecniche.

In questo scenario hanno tipicamente luogo tutta una serie di “inciampi” che lo rendono lontano da una prospettiva di “lean production”, centrata invece sull’evitare gli sprechi e massimizzare il valore.

Intanto, si inserisce un fattore di ritardo con cui il feedback viene comunicato da QA agli sviluppatori. Inoltre, comunicare tale feedback tramite un rapporto, ne degrada la quantità di informazione contenuta, favorendo incomprensioni ed errori, che portano a ulteriori ritardi e ripetizioni di attività. 

Anche lo scambio tra analisti e tester soffre dello stesso tipo di problema.

Inoltre si favorisce una de-responsabilizzazione, anche in buona fede, da parte degli sviluppatori. Assumendo che i colleghi del QA comunque facciano un attento lavoro di valutazione della qualità, in momenti di crisi ed emergenza, agli sviluppatori farà comodo pensare così “… credo non ci siano difetti gravi. Intanto rilascio. Comunque c’è QA che se salta fuori qualcosa lo scoprirà.". 

Ma c’è di peggio: immaginando dei canali di comunicazione essenzialmente unidirezionali (da analisti a QA, da QA a sviluppatori) ed escludendo dei canali tra QA e il gruppo di Product Management, si sprecano molte opportunità e obiettivi strategici che il testing può offrire. 

Infatti, con uno stretto contatto tra QA e sviluppatori si possono attuare pratiche come il Test Driven Development o il Behaviour Driven Development, che sfruttano i test per guidare gli sviluppare nel loro lavoro e renderli più produttivi e creare un prodotto con feature più mirate. 

Con uno stretto contatto tra analisti e QA, i tester possono rivedere e aiutare a migliorare le specifiche tecniche, prima che gli sviluppatori inizino a lavorarci sopra. Evitando così che quegli errori e quelle lacune si propaghino e consumino risorse e tempo preziosi. Inoltre, i tester avranno a disposizione maggiori informazioni relative al perché delle varie specifiche tecniche e anche dei requisiti, che consentirà loro di mettere in atto procedure di testing più efficaci.

Con un coinvolgimento diretto di QA con il Product Management, pratiche come il BDD possono aiutare anche a capire quali possono essere i vantaggi strategici di un prodotto e in che modo quel prodotto possa sperare di conseguire opportuni obiettivi di business.

Con interazioni frequenti tra QA, Product Management, analisti e sviluppatori, si possono svolgere iniziative molto efficaci di analisi dei rischi di qualità, che portano a migliori procedure di testing.

Quindi, per riassumere, le conseguenze negative di una ingenua introduzione di un gruppo di QA isolato sono:

1. allungamento del tempo di rilascio;
2. compressione del testing alle fasi finali di un rilascio, con conseguente riduzione della sua efficacia;
3. poca confidenza sul livello di qualità raggiunto, e quindi difficoltà nella gestione del progetto;
4. maggiori costi per il rilascio, e maggiori costi per gestire la bassa qualità del rilascio una volta che questo va in produzione. 

E la domanda allora diventa: “questi costi sono bilanciati dai benefici legati alle motivazioni per cui si introduce in gruppo di QA?” Generalmente no, almeno se li valutiamo in base all’economia dell’azienda, e non del singolo manager. 

Il vero beneficio che un gruppo di QA porta (e meglio ancora se invece di essere un gruppo viene costituito un team di QA) è legato al problema dello scaraffone e alla specializzazione.

Il trucco vincente è quindi quello di istituire il team di testing, ma renderlo permeabile ad interazioni frequenti e ricche con gli sviluppatori, con gli analisti e con i Product Manager. Solo così non diventa un silo isolato che ostacola e rende impossibile un “lean testing”. Ma occorre mettere in atto dei meccanismi per ridurre la possibile de-responsabilizzazione.

In un prossimo intervento vedremo come questo tipo di problema è stato affrontato in un contesto con varie decine di team agili.

Pubblicato originariamente come Articolo LinkedIn.