Come assicurare garanzia della qualità in tempi rapidi

Passaggio dalla garanzia della qualità all'assistenza per la qualità

Laura Daly Laura Daly
Sfoglia tra gli argomenti

Adattare i metodi di test tradizionali a una cultura Agile non è facile; i team si sentono obbligati a sacrificare la qualità del prodotto per garantire rilasci rapidi.

Per risolvere questi problemi, i team di Atlassian hanno adottato per primi un approccio diverso al testing Agile, noto come Assistenza per la qualità (Quality Assistance, QA). Invece di creare un team separato per l'esecuzione dei test e responsabile della qualità, un piccolo team di tecnici dell'Assistenza per la qualità promuove e insegna ai membri del team di sviluppo metodi di test sostenibili. Scopri di più su questo cambiamento e su come:

  • Creare una cultura della qualità
  • Riassegnare la responsabilità dei test agli sviluppatori
  • Prevenire i bug, piuttosto che rilevarli

Domande e risposte

Leggi le domande e le risposte di questa presentazione per scoprire come un team di 65 tecnici può creare e rilasciare rapidamente un prodotto di elevata qualità con soli sei tecnici QA.

D1: In quanto tempo gli sviluppatori riescono a far proprio questo tipo di approccio?

R1: Cambiare la cultura dei singoli individui è meno difficoltoso che agire a livello dell’intero team. Sono serviti cinque anni affinché il team di Jira Software raggiungesse la mentalità orientata alla qualità che ha oggi, ma non serve invece molto tempo ai singoli sviluppatori per acquisire questa forma mentis. Questi ultimi acquisiscono infatti rapidamente questo tipo di logica dai colleghi sviluppatori e apprendono in tempi brevi le competenze di testing tramite il lavoro in coppia e i workshop. La parte più complicata consiste nell'apprendimento delle nozioni relative ai rischi e al prodotto, che può richiedere diversi anni. Tuttavia, la condivisione della conoscenza tramite i demo e i lanci di QA possono ridurre questo lasso di tempo.

D2: Sono ancora necessari test case o questi servono soltanto per i test di regressione/automatizzati?

R2: I test case manuali basati su script non rientrano assolutamente nella nostra strategia. Se un test è un semplice "controllo", ovvero un insieme di passaggi predefiniti e una determinata affermazione, riteniamo che l'esecuzione del test da parte del computer sia più efficiente e meno incline all'errore. Se si tratta di un test vero e proprio, che richiede pensiero critico, libertà di analisi e valutazione dei rischi, è preferibile eseguirlo come parte di un testing esplorativo al fine di integrarvi gli aspetti della libertà e dell'intelligenza.

D3: In genere gli sviluppatori hanno un costo più elevato dei tester. Il loro impiego al posto dei tester, non implica un utilizzo poco efficiente del budget o del personale?

R3: Assolutamente: impiegare sviluppatori come tester per eseguire un passaggio di testing separato rappresenta uno spreco in termini economici e del tempo di lavoro degli sviluppatori. La stessa presenza di un passaggio di testing separato, anche se eseguito dai tester, rappresenta uno spreco economico e di tempo. Le story o i bug rimandati dai tester agli sviluppatori comportano non solo costi in termini di testing, ma anche di sviluppatori. La riduzione del tasso di rifiuto dal 100% al 4%, ci ha permesso di risparmiare parecchio tempo di sviluppo, normalmente sprecato per la rielaborazione delle story e la correzione di bug insignificanti prima del rilascio. Siamo stati inoltre in grado di risparmiare il tempo dedicato all'analisi, alla creazione di report, alla valutazione, alla riproduzione e alla correzione dei bug interni rilevati. Inoltre, dal momento che gli sviluppatori sono consapevoli che dovranno occuparsi in prima persona del testing, il codice è progettato da zero secondo modalità maggiormente testabili. Dal momento che la fase DoTing (developer-on-testing) era un passaggio intermedio del percorso di avanzamento della qualità upstream, abbiamo potuto rimuovere interamente il passaggio di testing separato. È stato un investimento provvisorio che ha dato ottimi risultati.

D4: I nostri sviluppatori e tester QA si trovano in fusi orari diversi. Questo modello funziona soltanto se si lavora nello stesso fuso orario? Come è possibile implementarlo nel caso di team remoti?

R4: Abbiamo fornito servizi di assistenza per la qualità da remoto con team basati in Polonia e Vietnam e tecnici QA basati in Australia. Non si tratta di una situazione di lavoro ideale, come quando si dispone di un esperto QA in sede, dal momento che un buon tecnico QA è tale in larga parte per il rapporto personale che instaura con gli sviluppatori. È facile che i tecnici QA che lavorano da remoto vengano esclusi dalle comunicazioni, senza contare che è molto più complicato valutare la cultura globale del team. Tuttavia, abbiamo eseguito con successo demo e lanci di QA e sessioni di lavoro in coppia da remoto tramite videochiamata direttamente tra il computer dello sviluppatore e quello del tecnico QA e la condivisione dello schermo.

D5: Le note di QA seguono una struttura basata su story o viene invece creata una knowledge base? Come vengono gestiti i rischi ricorrenti?

R5: Le note di QA seguono una struttura basata su story, pertanto l'individuazione dei modelli dei rischi ricorrenti rientra tra le attività dei tecnici QA. Con la crescita del team di QA di Jira Software, questo processo è diventato sempre più complicato, dal momento che non tutti i tecnici QA possiedono le stesse conoscenze. Fino ad ora, abbiamo affrontato questo problema con riunioni settimanali per la condivisione delle conoscenze e con pagine wiki in cui si tiene traccia dei rischi comuni o imprevisti. Stiamo raggiungendo il punto di massima scalabilità di questo approccio e stiamo dunque lavorando alla creazione di una knowledge base più strutturata con un database di regole eseguite su ogni commit. Quindi, ad esempio, se il database rileva che stai utilizzando un oggetto Utente nel codice di Jira Software, aggiungerà al ticket il commento: "L'oggetto Utente non può essere null se l'utente corrente è anonimo; verificane la gestione corretta". In questo modo, sarà possibile condividere le conoscenze dei tecnici QA e, nello scenario migliore, persino eliminare la necessità di lanci e demo di QA. Sarebbe l'ideale!