Migliori Pratiche sulla Strategia di Test per uno Scrum Team

Il piano di test Scrum meno equivale a POC con steroidi.

Al giorno d'oggi, i progetti di maggior successo iniziano con un Proof of Concept (POC), una valutazione relativamente piccola di un'idea, in cui la tecnologia e il pacchetto di funzionalità scelti verranno prima verificati, valutati per il potenziale impatto sugli utenti aziendali e quindi, una volta dimostrati degno di investimento, viene assegnato un team di progetto a grandezza naturale per progettare e fornire il prodotto completo e distribuirlo alla produzione.

Questo è il caso perfetto per un team Scrum. Il team può sviluppare rapidamente il prototipo, aggiungendo nuove funzionalità sostanziali a ogni sprint, mentre gli utenti aziendali possono osservare in tempo reale i rapidi progressi e come l'idea viene costruita da zero in appena 10 sprint. Lascia una forte impressione (che è comunque l'obiettivo principale del POC), ma ha anche una proprietà significativa: attività di test minime o assenti, e anche solo pensare al processo di test sarebbe uno scherzo.

Non è un'attività divertente all'interno di un team Scrum e alle persone piacerà soprattutto l'idea di sviluppare senza processi intorno a rallentarli. Questo è fondamentalmente ciò che qualsiasi attività di test farà implicitamente. E chi desidera una lentezza non necessaria durante il tempo necessario per impressionare di più l'utente finale?

Lo stato che si verifica se il team di progetto continua allo stesso modo dopo che il periodo POC è terminato è qualcosa che uso per chiamare POC sotto steroidi - un sistema di produzione che cresce in dimensioni e funzionalità, ma si comporta ancora come un POC - un aspirante prodotto completo con difetti nascosti e casi d'angolo inesplorati, in attesa solo di un serio incidente.

Ma prima che si converta lì, il team avrà più difficoltà da uno sprint all'altro per tenere il passo con le versioni stabili, poiché la risoluzione dei problemi di rotazione diventerà solo più complessa.

Ecco alcune tecniche che hanno dimostrato di funzionare quando ho avuto a che fare con problemi simili e che credo possano essere nominate best practice per implementare solidi processi di test, senza comunque ostacolare troppo il progresso dello sviluppo, perché è quello per cui tutti vogliamo essere un team Scrum.

Distribuisci il dolore

Dove altro dovremmo iniziare quando abbiamo a che fare con inutili fastidi piuttosto che dividere il dolore :).

E ciò che intendo con questo è creare un piano che richiederà piccole attività aggiuntive da parte degli sviluppatori qua e là, ma che contribuirà notevolmente all'obiettivo comune nel tempo, in modo incrementale ma coerente.

#1. Sviluppa il codice di unit test per ogni pezzo di nuovo codice creato

Se riesci a convincere i tuoi team di scrum ad aggiungere nella sua clausola Definition Of Done lo sviluppo di test unitari per ogni nuovo codice creato durante lo sprint, allora da una prospettiva a lungo termine, questo sarà un grande risultato.

Le ragioni sono abbastanza ovvie:

Costringerà gli sviluppatori a pensare a vari percorsi non standard del codice. –

• Tali unit test possono essere inseriti in pipeline DevOps automatizzate ed eseguiti con ogni singola distribuzione nell'ambiente di sviluppo o test. Inoltre, le metriche della pipeline possono essere facilmente esportate e quindi utilizzate per dimostrare agli utenti aziendali la percentuale di copertura dei casi di test direttamente associati al codice sorgente.

La cosa più importante è iniziare molto presto. Più tardi inizieranno a essere sviluppati i test unitari, più diventerà fonte di distrazione per gli sviluppatori aggiungerli in uno sprint.

• Ci vorrà uno sforzo significativo per sviluppare a ritroso i test unitari per il codice già esistente. Alcune parti del codice potrebbero essere create da un altro sviluppatore e l'esatta conoscenza di come dovrebbe funzionare in ogni singola parte del codice non è esattamente chiara allo sviluppatore attuale. In alcuni casi, può arrivare così lontano che l'aggiunta di un test unitario al codice modificato richiederà più tempo rispetto allo sviluppo della modifica della funzionalità per lo sprint (che è uno stato che nessuno ha calcolato di sicuro durante la pianificazione dello sprint).

#2. Creare una routine di esecuzione di tutte le parti dei test unitari nell'ambiente di sviluppo

Anche prima di creare una richiesta pull per l'unione del nuovo codice nel ramo Master, sarà un'attività standard testare sia il codice funzionalità che il codice unit test nell'ambiente di sviluppo. In questo modo sarà garantito che:

• Il codice unit test funziona effettivamente per ogni parte (alla fine è solo un altro codice che deve essere verificato). Questo passaggio molto spesso viene totalmente saltato. Si presume in qualche modo che se lo unit test è comunque collegato alla pipeline DevOps, verrà eventualmente eseguito e testato da qualche parte per impostazione predefinita. Tuttavia, questo non è altro che spingere i problemi ai livelli superiori delle attività di sprint, dove il team di solito ha meno tempo e più stress per finire ogni storia impegnata.
• Il nuovo codice funzione viene testato dallo sviluppatore per le funzionalità di base. Ovviamente, non ci si può aspettare da questo test che la funzionalità aziendale sarà completamente verificata, ma almeno questo test confermerà che il codice si comporta nel modo in cui lo sviluppatore lo intendeva (ignorando, per ora, il fatto che la logica aziendale potrebbe essere frainteso durante lo sviluppo).

#3. Aspettatevi l'esecuzione del test unitario dopo l'unione del codice nel ramo master

Una cosa è avere il codice funzionale sul ramo locale (dove nessuno tranne il proprietario del ramo sta sviluppando una nuova funzionalità), ma è una cosa completamente diversa avere lo stesso codice funzionante dopo la richiesta pull e unire nel ramo principale.

Il master branch contiene le modifiche di altri membri del team Scrum e, anche se i conflitti vengono risolti e tutto sembra a posto, il codice dopo l'unione e la risoluzione dei conflitti è fondamentalmente ancora un pezzo di codice non testato ed è rischioso inviarlo ulteriormente senza verificarlo prima funziona ancora bene.

Quindi ciò che si è rivelato efficace qui è semplicemente chiedere di eseguire lo stesso unit test – già fatto in precedenza sull'ambiente dev – anche sull'ambiente, che è costruito dalla versione del codice master branch.

Per gli sviluppatori, potrebbe essere un passaggio aggiuntivo che devono includere nella loro vita, ma non è un grande sforzo poiché, in questo caso, non deve essere inventato nulla di nuovo: basta rieseguire ciò che è già stato fatto una volta.

Ora, questo passaggio potrebbe essere saltato in un caso particolare:

• Gli unit test automatizzati nelle pipeline DevOps sono così completi che coprono già l'intero test manuale eseguito oltre a quello.

Sebbene raggiungere questo stato sia sicuramente fattibile, non ho mai sperimentato un tale stato nella vita reale. Probabilmente sarebbe anche troppo dispendioso in termini di tempo per gli sviluppatori creare unit test automatizzati così dettagliati. Potrebbe diventare facilmente inaccettabile per il product owner lasciare che il team dedichi così tanto tempo a questa attività, poiché avrebbe un impatto esplicito sul numero di storie consegnate all'interno di uno sprint.

Tuttavia, la preferenza per il contenuto dello sprint non deve mai essere una scusa per non eseguire i test unitari o addirittura per minimizzarli. In questo modo, il team convertirà di nuovo in uno stato tale che il codice non ha troppa copertura del test unitario, e quindi per un recupero, potrebbe essere già troppo tardi (di nuovo, lo sforzo maggiore per il completamento del test unitario rispetto all'effettivo cambio di codice per uno sprint).

Per tutti questi motivi, consiglierei la riesecuzione degli unit test sulla versione del codice master senza esitazioni. È uno sforzo così basso rispetto al valore che porterà.

Effettuerà il controllo finale della disponibilità del ramo master per la fase di test del rilascio. Inoltre, aiuterà a trovare la maggior parte dei bug tecnici (es. bug che impediscono al codice sorgente di essere eseguito con successo fino alla fine con successo), lasciando alla fase successiva concentrarsi esclusivamente sulla verifica della funzionalità aziendale.

Preparati per i test funzionali

Tutte le attività di test precedenti devono portare a una conclusione specifica: il codice master branch è privo di bug tecnici ed eseguibile senza problemi per flussi funzionali end-to-end.

Questa è una fase che può essere facilmente coperta da una sola persona, e questa persona non ha nemmeno bisogno di avere un background tecnico.

In realtà, è molto meglio se questo viene eseguito da qualcuno disconnesso dagli sviluppatori ma con una consapevolezza funzionale di come gli utenti aziendali si aspettano che si comporti il ​​codice. Ci sono due attività principali da completare:

#1. Nuove storie di sprint mirate al test funzionale

Ogni sprint dovrebbe idealmente portare alcune nuove funzionalità (incremento dell'obiettivo dello sprint) che prima non esistevano, e quindi deve essere verificato. È importante garantire che il nuovo software funzioni a tal punto che gli utenti aziendali siano felici di averlo ora, poiché ovviamente non vedevano l'ora di averlo almeno per tutto l'ultimo sprint :).

È un'esperienza così triste quando la funzionalità (a lungo) promessa viene finalmente annunciata per essere rilasciata, solo per scoprire l'altro giorno che in realtà non funziona bene.

Pertanto, testare correttamente la nuova funzionalità di sprint è fondamentale. Per fare in modo che ciò abbia successo, è buona norma raccogliere in anticipo casi di test importanti e dalle parti interessate pertinenti (dal proprietario del prodotto o anche dagli utenti finali) e fare un elenco di tutti i casi di test necessari per il contenuto all'interno lo sprint.

Questo potrebbe sembrare travolgente a prima vista, ma dalla mia esperienza, è di nuovo totalmente gestibile da una sola persona. Poiché gli sprint sono per lo più piuttosto brevi (come un periodo di due settimane), non sono quasi mai troppi nuovi contenuti in ogni caso, poiché lo sprint contiene anche attività aggiuntive come storie di debiti tecnici, documentazione, storie di progettazione/spike, ecc.

I casi di test vengono quindi eseguiti con l'obiettivo di verificare principalmente la funzionalità desiderata. In caso di problemi con i risultati, viene contattato solo lo sviluppatore pertinente (colui che possiede le modifiche relative a questo particolare difetto) per risolvere il problema, si spera rapidamente.

In questo modo, gli sviluppatori trascorreranno il minimo tempo connesso ai test funzionali e potranno comunque concentrarsi sulle attività che preferiscono.

#2. Esecuzione dei casi di test di regressione

L'altra parte del test funzionale sarà garantire che tutto ciò che ha funzionato fino ad ora funzionerà anche dopo il prossimo rilascio. Ecco a cosa servono i test di regressione.

I casi di test per i test di regressione sono i migliori se vengono regolarmente mantenuti e rivisitati prima di ogni rilascio. Sulla base delle specifiche concrete del progetto, è meglio mantenerle semplici ma coprire la maggior parte delle funzionalità fondamentali e gli importanti flussi end-to-end che attraversano l'intero sistema.

Di solito, ogni sistema ha tali processi che toccano molte aree diverse, quelli sono i migliori candidati per i casi di test di regressione.

In alcuni casi, i test di regressione coprono anche implicitamente anche nuove funzionalità nello sprint, ad esempio, se la nuova storia nello sprint sta cambiando una parte particolare del flusso esistente.

Quindi, nella maggior parte dei casi, non è affatto complesso completare i test di regressione insieme ai test di funzionalità delle nuove storie di sprint, soprattutto se questo viene fatto regolarmente prima di ogni rilascio di produzione e la periodicità dei rilasci di produzione non è troppo piccola.

Insistere sull'esecuzione di test di garanzia della qualità prima di ogni rilascio di produzione

Il test Quality Assurance (QA) è il passaggio finale prima del rilascio in produzione e spesso questo test viene saltato in quanto non importante. Soprattutto se il team di mischia è gestito in modo aggressivo per i nuovi contenuti.

Anche gli utenti business diranno di essere interessati a nuove funzionalità e non tanto a preservare la funzionalità o mantenere basso il numero di difetti. Ma poi di nuovo: nel tempo, questo è il motivo principale per cui il team di sviluppo dovrà rallentare alla fine, e quindi gli utenti aziendali non otterranno comunque ciò che chiedono.

Il test QA deve essere eseguito esclusivamente da persone al di fuori del team Scrum, idealmente dagli stessi utenti aziendali in un ambiente dedicato, il più vicino possibile alla produzione futura. In alternativa, il proprietario del prodotto può sostituire qui gli utenti finali.

In ogni caso, questo dovrebbe essere un test pulito e funzionale dal punto di vista dell'utente finale, senza alcuna connessione con il team di sviluppo Scrum. Presenterà una visione finale del prodotto e verrà utilizzato in un modo che forse nessuno del team di mischia aveva previsto (non è affatto un caso ideale, ma sicuramente può succedere). C'è ancora tempo per le correzioni dell'ultimo minuto.

In alternativa, potrebbe diventare chiaro che le aspettative non sono state ben comprese dal team di scrum e, in tal caso, almeno possiamo concordare un piano di follow-up, ancora molto prima dell'effettivo rilascio in produzione. Questo, ancora una volta, non è un caso ideale, ma è comunque molto meglio come ammettere il fallimento subito dopo aver segnalato un rilascio di produzione riuscito.

Dove andare dopo da qui?

Applicare queste pratiche al lavoro quotidiano di scrum può portarti seriamente ad abitudini di rilascio dello sprint più stabili e prevedibili, senza ritardare i rilasci di produzione o spendere l'intero sprint solo a prepararsi per il prossimo rilascio, o anche senza costringere tutti nel team di scrum a fare qualcosa che non fanno non mi piace molto o non so come fare comunque in modo efficace per la maggior parte dello sprint, cioè.

Ma sicuramente non è necessario che ti fermi qui.

L'inclusione del test delle prestazioni è un argomento da nominare qui. Questi vengono spesso ignorati o ritenuti non necessari, raschiando nel primo round di "ottimizzazione delle attività di mischia". Tuttavia, ero sempre in dubbio su come ci si possa aspettare che il sistema di produzione si evolva nel tempo se non viene controllato regolarmente per le prestazioni.

Salire di un livello significa anche introdurre test automatizzati.

Ho già coperto un gruppo di test automatizzati (test unitari nelle pipeline). Tuttavia, è possibile sviluppare test di regressione end-to-end completamente automatizzati ed eseguiti da soli dopo ogni distribuzione nell'ambiente di test. Ciò libererebbe ancora di più lo scrum team di sviluppo, ma richiede un team dedicato per sviluppare e mantenere tali test automatizzati. Diventerebbe un lavoro costante, poiché ogni volta che il codice di produzione cambia, alcuni test automatizzati esistenti possono diventare non validi e quindi devono essere aggiornati per continuare a funzionare nelle pipeline. È uno sforzo per cui solo pochi sono disposti a pagare, i vantaggi per il team di sviluppo sarebbero comunque grandi.

Questi sono argomenti che vanno molto al di là dell'ambito di questo articolo e che determinano il programma e la tempistica giusti per ogni tipo di test menzionato qui, in modo da poterlo fare all'interno di una finestra di sprint. Sarò felice di tuffarmi la prossima volta!