Una strada per test agili migliori

Il World Quality Report annuale creato da Capgemini mostra che il 42% degli intervistati indica la "mancanza di esperienza nei test professionali" come una sfida nell'applicazione dei test allo sviluppo Agile. Sebbene l'avvento di Agile abbia portato la maggiore velocità delle iterazioni per lo sviluppo del software, in alcuni casi ciò è avvenuto a scapito della qualità.

L'agguerrita concorrenza sta spingendo i team a fornire costantemente nuovi aggiornamenti di prodotto, ma questo a volte ha un suo costo, inclusa una minore attenzione verso i test. Alcuni, come Rob Mason, vanno ancora oltre e sostengono che Agile stia uccidendo i test del software. Di recente, Facebook ha cambiato il suo motto da "muoviti velocemente e rompi le cose" a "muoviti velocemente con un'infrastruttura stabile" nel tentativo di risolvere le tentazioni di sacrificare la qualità.

Quindi, come è possibile integrare meglio i test nel nuovo mondo dello sviluppo software Agile? Test agili.

I test tradizionali sono piuttosto ingombranti e dipendono da molta documentazione. Il test Agile è un approccio al processo di test che imita i principi dello sviluppo del software Agile in base al quale:

• I test vengono eseguiti molto più spesso,
• I test si basano meno sulla documentazione e più sulla collaborazione dei membri del team, e
• Alcune attività di test sono intraprese non solo dai tester ma anche dagli sviluppatori.

Negli ultimi sette anni, ho trasferito molti team ai test Agile e ho lavorato fianco a fianco con i tester per aiutare i loro processi ad adattarsi alla nuova metodologia. In questo articolo, condividerò alcuni dei suggerimenti più efficaci che ho imparato lungo il mio percorso per migliorare i test Agile. Sebbene sia naturale avere attrito tra velocità e qualità all'interno delle pratiche Agile, questo articolo tratterà alcune tecniche che possono essere utilizzate per aumentare la qualità dei test senza compromettere l'agilità. La maggior parte dei suggerimenti qui delineati richiederà il coinvolgimento del team, quindi sarà vantaggioso che sia gli sviluppatori che i tester partecipino alla pianificazione.

Formalizzare un processo del ciclo di test di rilascio

Un problema con i test è l'assenza del ciclo di test di rilascio, nessun programma di rilascio o richieste di test irregolari. Le richieste di test su richiesta rendono difficile il processo di QA, soprattutto se i tester gestiscono più progetti.

Molti team eseguono solo una singola build dopo ogni sprint, il che non è l'ideale per i progetti Agile. Potrebbe essere utile passare a versioni una volta alla settimana, passando gradualmente a più build a settimana. Idealmente, le build di sviluppo e i test dovrebbero essere eseguiti quotidianamente, il che significa che gli sviluppatori inviano il codice al repository ogni giorno e le build devono essere eseguite a un'ora specifica. Per fare un ulteriore passo avanti, gli sviluppatori sarebbero in grado di distribuire nuovo codice su richiesta. Per implementare ciò, i team possono utilizzare un processo di integrazione continua e distribuzione continua (CI/CD). CI/CD limita la possibilità di una build non riuscita il giorno di una versione principale.

Quando si combinano CI/CD e automazione dei test, è possibile rilevare in anticipo i bug critici, consentendo agli sviluppatori di avere abbastanza tempo per correggere i bug critici prima del rilascio programmato del client. Uno dei principi di Agile afferma che il software funzionante è la misura primaria del progresso. In questo contesto, un ciclo di rilascio formalizzato rende più agile il processo di test.

Potenzia i tester con gli strumenti di distribuzione

Uno dei punti di attrito comuni per i test è la distribuzione del codice in un ambiente di staging. Questo processo dipende dall'infrastruttura tecnica che il tuo team potrebbe non essere in grado di influenzare. Tuttavia, se è disponibile una certa flessibilità, è possibile creare strumenti per persone non tecniche come tester o project manager che consentirebbero loro di distribuire la base di codice aggiornata per testare se stessi.

Ad esempio, in uno dei miei team, abbiamo utilizzato Git per il controllo della versione e Slack per la comunicazione. Gli sviluppatori hanno creato uno Slackbot che aveva accesso a Git, script di distribuzione e una macchina virtuale. I tester sono stati in grado di eseguire il ping del bot con un nome di ramo acquisito da GitHub o Jira e averlo distribuito in un ambiente di staging.

Questa configurazione ha liberato molto tempo per gli sviluppatori riducendo gli sprechi di comunicazione e le continue interruzioni quando i tester hanno dovuto chiedere agli sviluppatori di implementare un ramo per i test.

Sperimenta con TDD e ATDD

Lo sviluppo basato su test (TDD) è un tipo di processo di sviluppo software che pone molta enfasi sulla qualità. Tradizionalmente, uno sviluppatore scrive il codice e poi qualcuno lo testa e segnala se sono stati trovati bug. In TDD, gli sviluppatori scrivono gli unit test prima ancora di scrivere qualsiasi codice che completerebbe una user story. I test inizialmente falliscono fino a quando lo sviluppatore non scrive la quantità minima di codice per superare i test. Successivamente, il codice viene rifattorizzato per soddisfare i requisiti di qualità del team.

Lo sviluppo guidato dai test di accettazione (ATDD) segue una logica simile a TDD ma, come suggerisce il nome, si concentra sui test di accettazione. In questo caso, i test di accettazione vengono creati prima dello sviluppo in collaborazione con sviluppatori, tester e richiedenti (cliente, proprietario del prodotto, analista aziendale, ecc.). Questi test aiutano tutti i membri del team a comprendere i requisiti del cliente prima che venga scritto qualsiasi codice.

Tecniche come TDD e ATDD rendono i test più agili spostando le procedure di test nelle prime fasi del ciclo di vita dello sviluppo. Quando si scrivono scenari di test all'inizio, gli sviluppatori devono comprendere molto bene i requisiti. Ciò riduce al minimo la creazione di codice non necessaria e risolve anche eventuali incertezze del prodotto all'inizio del ciclo di sviluppo. Quando le domande oi conflitti sui prodotti emergono solo nelle fasi successive, i tempi e i costi di sviluppo aumentano.

Scopri le inefficienze monitorando il movimento della scheda attività

In uno dei miei team, avevamo uno sviluppatore estremamente veloce, soprattutto con piccole funzionalità. Avrebbe ricevuto molti commenti durante la revisione del codice, ma il nostro Scrum Master e io l'abbiamo cancellato come mancanza di esperienza. Tuttavia, quando ha iniziato a codificare funzionalità più complesse, i problemi sono diventati più evidenti. Aveva sviluppato un modello per passare il codice al test prima che fosse completamente pronto. Questo modello si sviluppa in genere quando c'è una mancanza di trasparenza nel processo di sviluppo, ad esempio, non è chiaro quanto tempo le persone trascorrono in un determinato compito.

A volte, gli sviluppatori affrettano il loro lavoro nel tentativo di ottenere funzionalità il prima possibile e "esternalizzare" la qualità ai tester. Una tale configurazione sposta solo il collo di bottiglia più in basso durante lo sprint. La garanzia della qualità (QA) è la rete di sicurezza più importante di cui dispone il team, ma ciò può significare che l'esistenza del QA offre agli sviluppatori la possibilità di rinunciare a considerazioni sulla qualità.

Molti moderni strumenti di gestione dei progetti hanno la capacità di tenere traccia del movimento delle schede attività su una bacheca Scrum o Kanban. Nel nostro caso, abbiamo utilizzato Jira per analizzare cosa è successo con i compiti dello sviluppatore in questione e fare confronti con altri sviluppatori del team. Abbiamo scoperto che:

• I suoi compiti hanno speso quasi il doppio del tempo nella colonna di test della nostra scheda;
• I suoi compiti sarebbero stati restituiti molto più spesso dal QA per un secondo o terzo round di correzione.

Quindi, oltre a dover dedicare più tempo ai suoi compiti, i tester hanno dovuto farlo anche più volte. Il nostro processo opaco ha fatto sembrare che lo sviluppatore fosse davvero veloce; tuttavia, ciò si è rivelato falso quando abbiamo preso in considerazione il tempo di test. Spostare le storie degli utenti avanti e indietro non è ovviamente un approccio snello.

Per risolvere questo problema, abbiamo iniziato discutendo onestamente con questo sviluppatore. Nel nostro caso, semplicemente non era consapevole di quanto fosse dannoso il suo schema di lavoro. Era proprio il modo in cui si era abituato a lavorare nella sua precedente azienda, che aveva requisiti di qualità inferiori e un pool di tester più grande. Dopo la nostra conversazione e con l'aiuto di alcune sessioni di programmazione in coppia con il nostro Scrum master, è gradualmente passato a un approccio allo sviluppo di qualità superiore. Grazie alle sue capacità di codifica veloce, era ancora un ad alte prestazioni, ma lo "spreco" rimosso del processo di controllo qualità ha reso l'intero processo di test molto più agile.

Aggiungi l'automazione dei test allo Skillset del team QA

Il test in progetti non Agile comporta attività come l'analisi del test, la progettazione del test e l'esecuzione del test. Queste attività sono sequenziali e richiedono un'ampia documentazione. Quando un'azienda passa ad Agile, il più delle volte, la transizione si concentra principalmente sugli sviluppatori e non tanto sui tester. Smettono di creare un'ampia documentazione (un pilastro dei test tradizionali) ma continuano a eseguire test manuali. Tuttavia, il test manuale è lento e in genere non è in grado di far fronte ai rapidi cicli di feedback di Agile.

L'automazione dei test è una soluzione popolare a questo problema. I test automatici rendono molto più semplice testare funzionalità nuove e piccole, poiché il codice di test può essere eseguito in background mentre sviluppatori e tester si concentrano su altre attività. Inoltre, poiché i test vengono eseguiti automaticamente, la copertura dei test può essere molto più ampia rispetto agli sforzi di test manuali.

I test automatici sono parti di codice software simili alla codebase che viene testata. Ciò significa che le persone che scrivono test automatizzati avranno bisogno di competenze tecniche per avere successo. Esistono molte varianti diverse di come i test automatizzati vengono implementati in diversi team. A volte gli sviluppatori stessi assumono il ruolo di tester e aumentano la base di codice di test con ogni nuova funzionalità. In altri team, i tester manuali imparano a utilizzare gli strumenti di automazione dei test o viene assunto un tester tecnico esperto per automatizzare il processo di test. Qualunque sia il percorso intrapreso dal team, l'automazione porta a test molto più agili.

Gestisci le priorità di test

Con lo sviluppo di software non Agile, i tester vengono generalmente assegnati in base al progetto. Tuttavia, con l'avvento di Agile e Scrum, è diventato comune per gli stessi professionisti del QA operare su più progetti. Questa responsabilità sovrapposta può creare conflitti nei programmi e portare i tester a perdere le cerimonie critiche quando un tester dà la priorità ai test di rilascio di un team rispetto alla sessione di pianificazione dello sprint di un altro.

Il motivo per cui i tester a volte lavorano su più progetti è ovvio: raramente c'è un flusso costante di attività per i test per ricoprire un ruolo a tempo pieno. Pertanto, potrebbe essere difficile convincere le parti interessate ad avere una risorsa di test dedicata assegnata a un team. Tuttavia, ci sono alcune attività ragionevoli che un tester può svolgere per riempire i propri tempi di inattività quando non è impegnato in attività di test.

Assistenza clienti

Una possibile configurazione è fare in modo che il tester trascorra il tempo di inattività dello sprint ad aiutare il team di supporto del cliente. Affrontando costantemente i problemi dei clienti, il tester ha una migliore comprensione dell'esperienza dell'utente e di come migliorarla. Sono in grado di contribuire alle discussioni durante le sessioni di pianificazione. Inoltre, diventano più attenti durante le loro attività di test poiché hanno una maggiore familiarità con il modo in cui i clienti utilizzano effettivamente il loro software.

Gestione del prodotto

Un'altra tecnica per gestire le priorità dei tester consiste essenzialmente nel renderli junior product manager che eseguono test manuali. Questa è anche una soluzione praticabile per riempire il tempo fuori servizio di un tester perché i product manager junior dedicano molto tempo a creare requisiti per le storie degli utenti e quindi hanno una conoscenza approfondita della maggior parte delle attività.

Automazione dei test

Come abbiamo discusso in precedenza, i test manuali sono spesso inferiori all'automazione. In questo contesto, la spinta all'automazione può essere associata al fatto che un tester dedichi la sua piena attenzione al team e utilizzi il suo tempo libero imparando a lavorare con strumenti di automazione dei test come Selenium.

Riepilogo: test agili di qualità

Rendere i test più agili è un'inevitabilità che molti team di sviluppo software devono affrontare. Tuttavia, la qualità non dovrebbe essere compromessa adottando una mentalità "test il più velocemente possibile". È imperativo che una transizione Agile includa un passaggio ai test Agile e ci sono alcuni modi per raggiungere questo obiettivo:

• Formalizzare un processo del ciclo di test di rilascio.
• Offri ai tester strumenti di distribuzione.
• Sperimenta lo sviluppo guidato dai test e lo sviluppo guidato dai test di accettazione.
• Scopri le inefficienze monitorando il movimento della scheda attività.
• Aggiungi l'automazione dei test allo skillset del team QA.
• Gestisci le priorità dei tester.

Ogni anno, il software migliora e le aspettative degli utenti aumentano. Inoltre, man mano che i clienti si abituano a prodotti di alta qualità dei migliori marchi di software come Google, Apple e Facebook, queste aspettative si trasferiscono anche ad altri prodotti software. Pertanto, è probabile che l'enfasi sulla qualità sia ancora più importante nei prossimi anni. Questi test e miglioramenti complessivi del processo di sviluppo possono rendere i test più agili e garantire un elevato livello di qualità del prodotto.