La gestione dei progetti a cascata divide lo sviluppo e i test in due diverse fasi: gli sviluppatori creano una funzione e poi la passano al team di controllo di qualità per i test. Il team di controllo di qualità scrive ed esegue piani di test dettagliati. Inoltre, durante il controllo scrupoloso delle regressioni nelle funzioni esistenti archivia i difetti che potrebbero essere stati causati da nuovi lavori.
Molti team che utilizzano questi modelli di test a cascata o altri modelli di test tradizionali scoprono che, man mano che il prodotto cresce, la quantità di test aumenta in modo esponenziale e il controllo di qualità inevitabilmente non riesce a stare al passo. I responsabili di progetto devono affrontare una scelta difficile: ritardare il rilascio o lesinare sui test (ti lascio indovinare qual è l'opzione che vince il 99% delle volte). Nel frattempo, lo sviluppo si è spostato su qualcos'altro. Quindi non solo il debito tecnico aumenta, ma la gestione di ogni difetto richiede un costoso cambio di contesto tra due parti della base del codice. In altre parole: al danno si aggiunge la beffa.
A peggiorare le cose contribuisce il fatto che i team di controllo di qualità vengono tradizionalmente premiati in base al numero di bug individuati, il che mette gli sviluppatori sulla difensiva. E se per gli sviluppatori e il team di controllo di qualità ci fosse un modo migliore per ridurre il numero di bug nel codice eliminando al contempo quei dolorosi compromessi che i responsabili di progetto devono fare? Il risultato non sarebbe un software completo migliore?
Accedi ai test Agile e DevOps.
Passaggio dai metodi di test tradizionali a quelli Agile
L'obiettivo dei team Agile e DevOps è di fornire in modo sostenibile nuove funzioni di qualità. Tuttavia, le metodologie di test tradizionali semplicemente non si prestano a un framework Agile o DevOps. Il ritmo di sviluppo richiede un nuovo approccio per garantire la qualità in ogni build. In Atlassian, testiamo in modo Agile. Dai un'occhiata dettagliata al nostro approccio ai test con Penny Wyatt, Senior QA Team Lead di Jira Software.
Proprio come avviene con una carta di credito, il debito iniziale è piccolo, ma presto cresce a dismisura, indebolendo il team in termini di agilità critica. Per contrastare la crescita incontrollata del debito tecnico, in Atlassian consentiamo (anzi: ci aspettiamo) che i nostri sviluppatori siano dei grandi sostenitori della qualità. Siamo convinti che gli sviluppatori apportino competenze chiave che aiutano a promuovere la qualità nel prodotto:
- Gli sviluppatori sono bravi a risolvere i problemi del codice.
- Gli sviluppatori che scrivono i propri test sono più inclini a correggerli in caso di insuccesso.
- Gli sviluppatori che comprendono i requisiti delle funzioni e le loro implicazioni di test generalmente scrivono codice migliore.
Riteniamo che ogni storia utente nel backlog richieda sia codice delle funzioni che codice di test automatizzato. Sebbene alcuni team assegnino agli sviluppatori il codice delle funzioni mentre il team di test esegue test automatizzati, riteniamo più efficace che un singolo ingegnere fornisca il set completo.
Gestisci i bug nelle nuove funzioni e le regressioni nelle funzioni esistenti in modo diverso. Se durante lo sviluppo emerge un bug, prenditi il tempo necessario per comprendere l'errore, correggerlo e andare avanti. Se appare una regressione (cioè, se qualcosa che ha funzionato prima non funziona più), è probabile che appaia di nuovo. Crea un test automatizzato per proteggerti da tale regressione in futuro.
Questo modello non implica il fatto che gli sviluppatori lavorino da soli. È importante che il team includa anche ingegneri del controllo di qualità. Il controllo di qualità offre una prospettiva importante allo sviluppo di una funzione e gli ingegneri competenti sanno dove di solito si nascondono i bug e possono fornire agli sviluppatori dei consigli su probabili gotcha.
Il tocco umano tramite test esplorativi
Nei nostri team di sviluppo, i membri del team di controllo di qualità collaborano con gli sviluppatori per condurre test esplorativi, una pratica preziosa per evitare bug più gravi durante lo sviluppo. Per questo motivo, analogamente alla revisione del codice, la conoscenza relativa ai test viene trasferita all'interno del team di sviluppo. Quando gli sviluppatori diventano tester migliori, viene fornito un codice migliore sin dall'inizio.
Ma i test esplorativi non sono test manuali? La risposta è no, quanto meno non nello stesso senso dei test di regressione manuali. I test esplorativi costituiscono un approccio verso i test basato sul rischio e il pensiero critico, e consentono alla persona che li esegue di utilizzare la propria conoscenza dei rischi, dei dettagli dell'implementazione e delle esigenze dei clienti. Conoscere questi aspetti in una fase tempestiva del processo di test consente allo sviluppatore o all'ingegnere del controllo di qualità di individuare i problemi in modo rapido e completo, senza che siano necessari casi di test con script, piani di test dettagliati o requisiti. Riteniamo che sia molto più efficace dei test manuali tradizionali, perché possiamo riportare le informazioni dalle sessioni di test esplorative al codice originale e ai test automatizzati. I test esplorativi sono anche utili in termini di esperienza di utilizzo della funzione e a tale riguardo offrono informazioni diverse rispetto a quelle fornite dai test con script.
Il mantenimento della qualità implica una combinazione di test esplorativi e automatizzati. Man mano che vengono sviluppate nuove funzioni, i test esplorativi assicurano che il nuovo codice soddisfi lo standard di qualità in un senso più ampio rispetto ai soli test automatizzati. Ciò include la facilità d'uso, un design visivo piacevole e l'utilità generale della funzione oltre alle solide protezioni contro le regressioni fornite dai test automatizzati.
Cambiare può essere davvero difficile
Vorrei concludere con un aneddoto personale che sintetizza efficacemente la mia esperienza con i test Agile. Ricordo di aver gestito, all'inizio della mia carriera, un team di ingegneri che manifestava una forte resistenza alla scrittura di test automatizzati perché, a loro avviso, si tratta di un'attività riservata al controllo di qualità. Dopo aver condotto diverse iterazioni di codice con bug e ascoltato tutti i motivi per i quali i test automatizzati avrebbero rallentato il team, mi sono impuntato, pretendendo che tutto il nuovo codice venisse comprovato da test automatizzati.
Dopo una singola iterazione, il codice ha iniziato a migliorare. E lo sviluppatore che era più fermamente contrario alla scrittura di test alla fine è stata la persona che è entrata in azione quando un test non è riuscito! Nelle successive iterazioni, i test automatizzati sono cresciuti, sono stati adattati ai vari browser e hanno migliorato la nostra cultura di sviluppo. Certo, approntare una funzione ha richiesto più tempo. Tuttavia, i bug e le rilavorazioni sono diminuiti in modo significativo, facendoci risparmiare alla fine enormi quantità di tempo.
Cambiare raramente è facile. Tuttavia, analogamente alla maggior parte delle cose che vale la pena provare, se ti metti all'opera e crei nuovi schemi per te stesso, l'unica domanda che alla fine ti rimarrà è la seguente: "Perché non l'abbiamo fatto prima?"
