Gruppi di test autonomi

È convinzione comune che colui che ha sviluppato un pezzo di codice sia la persona meno adatta a testarlo, come afferma la Legge di Weinberg (L23):

Uno sviluppatore non è adatto a testare il suo codice.

Di conseguenza, si preferisce spesso che il testing sia affidato ad un gruppo di tester autonomi. Questo implica infatti una serie di vantaggi, sia tecnici che e psicologici:

• Aspetti tecnici:
  • maggiore specializzazione: si evita così di richiedere che i propri sviluppatori siano anche esperti di testing;
  • maggiore conoscenze delle tecniche di verifica e convalida e dei relativi tool: chi fa il tester di lavoro acquisisce competenze specifiche sui tool e sugli strumenti di testing (spesso complessi), oltre che sui concetti di copertura e mutazioni.
• Aspetti psicologici:
  • distacco dal codice: a causa dell’assenza di modelli mentali precedenti su come il software dovrebbe operare, un tester esterno pone maggiore attenzione agli aspetti spesso trascurati o dimenticati;
  • indipendenza nella valutazione: una persona che testa il proprio codice è incentivata a non trovare molti errori in quanto potrebbe suggerire un lavoro di dubbia qualità in fase di sviluppo. Un gruppo specializzato nel testing è invece incentivato a trovarne il più possibile per giustificare il loro impiego.

Ci sono tuttavia anche una serie di svantaggi legati all’avere un gruppo di tester autonomo. Innanzitutto, i problemi più ovvi sono legati all’aspetto tecnico: il fatto che i tester diventino specializzati nel testing significa che perderanno con il tempo la capacità di progettare e codificare, oltre a possedere una minore conoscenza dei requisiti del progetto.

Nell’analisi di Elisabeth Hendrickson denominata “Better testing — worse quality?” viene analizzata poi la tecnica sotto un punto di vista psicologico: come è possibile che un maggior investimento nel team di testing porti a un calo delle prestazioni in termini di numero di errori nel codice?

La risposta pare dipendere dal concetto di responsabilità: seppur vero che l’attività di testing è compito del tester, è anche vero che è lo sviluppatore stesso che ha il compito di fare test di unità del proprio codice — il team di testing dovrebbe occuparsi solo di quello funzionale o di integrazione. Spesso però, a fronte di un aumento del personale nel team di testing e specialmente quando una deadline è vicina, il team di sviluppo tende a spostare la responsabilità di trovare gli errori ai tester, abbassando la qualità del codice.
Il team di testing troverà sì gli errori, riconsegnando il codice agli sviluppatori per correggerli, ma questo passaggio ulteriore implica una notevole perdita di tempo e risorse.

Inoltre, la presenza di un team di testing dedicato può generare pressioni negative sul team di sviluppo: ogni sviluppatore potrebbe sentirsi sotto costante valutazione da parte del team di testing.

Possibili alternative

Una possibile soluzione alle criticità appena evidenziate consisterebbe nella rotazione del personale: una stessa persona potrebbe ricoprire il ruolo di sviluppatore per un progetto e di tester per un altro. Questo approccio mostra diversi vantaggi, tra cui:

• evitare pressioni negative: ricoprendo diversi ruoli in diversi progetti, il personale non si dovrebbe sentire giudicato o giudicante;
• evitare il progressivo depauperamento tecnico dovuto ad all’eccessiva specializzazione;
• evitare lo svuotamento dei ruoli.

C’è però da considerare un certo aumento dei costi di formazione per via del raddoppio delle responsabilità individuali e un parallelo aumento della difficoltà di pianificazione: potrebbe succedere che la stessa persona debba lavorare a più progetti contemporaneamente, dovendo quindi dividere il proprio tempo e le proprie competenze.

Un’altra possibile alternativa consiste nella condivisione del personale, che prevede che siano gli stessi sviluppatori a occuparsi del testing: ciò permette di sopperire al problema di scarsa conoscenza del software in esame e del relativo dominio applicativo ma, oltre a far riemergere le criticità individuate precedentemente, aumenta le difficoltà nella gestione dei ruoli.