Utilizzando l’analisi delle lacune nel processo di test per allineare sviluppatori e tester

È opinione diffusa che sviluppatori e tester vadano avanti come gesso e formaggio. Gli sviluppatori spesso guardano dal basso il naso ai tester, vedendoli come un ostacolo inflessibile e inutile sullo sviluppo di nuovo codice che non riescono a fornire dettagli chiari nei loro bug ticket. Allo stesso modo, i tester spesso vedono gli sviluppatori con irritazione per non averli tenuti informati delle modifiche al codice e per aver spinto nuove modifiche durante i cicli di test. Questo è il motivo per cui l’analisi delle lacune nel processo di test QA può essere particolarmente utile per allineare sia gli sviluppatori che i tester.

Mentre questa vista può essere apocrifa, è spesso il caso è che gli sviluppatori e tester non comunicano bene. Spesso la comunicazione avviene solo tramite la gestione (project manager e manager di linea) o tramite biglietti in Jira. Il risultato è che i test spesso si rivelano inadeguati. In particolare, troppo spesso il nuovo codice è scarsamente testato o non testato affatto. La ricerca ha dimostrato che questo nuovo codice non testato è la più grande fonte di bug e fallimenti futuri. Questo è dove il concetto di Test Gap Analysis entra in gioco.

In questo blog, esploreremo cos’è l’analisi del gap di test, mostreremo come può aiutare a identificare il codice che deve essere testato ed esplorare se questo approccio è la panacea che può colmare il divario tra sviluppatori e tester.

Che cosa è Test Gap Analysis?

Quando si sviluppa per la prima volta un sistema software, è facile essere sicuri di testare l’intero sistema. I tester sono in grado di prendere le specifiche del codice e utilizzare una combinazione di test pianificati ed esplorativi per assicurarsi di testare ogni parte mobile della base di codice. Tuttavia, la maggior parte del software non è statico. Le aziende producono rilasci periodici monolitici di codice a lunga durata o impiegano un certo livello di integrazione continua e distribuzione continua (CI/CD). In entrambi i casi, la base di codice è in continua evoluzione. Tuttavia, troppo spesso i casi di test non vengono aggiornati alla stessa velocità. A volte i tester semplicemente non sanno che è stata apportata una modifica al codice. Altre volte, la modifica del codice viene spinta subito dopo l’esecuzione di un particolare set di test. Questi test sembrano essere passati, ma la modifica del codice potrebbe averli interrotti.

Test Gap Analysis è il processo di identificazione di queste lacune in cui il nuovo codice è stato distribuito ma non è ancora stato testato. Ciò richiede una combinazione di analisi statica di tutte le modifiche al codice e analisi dinamica di tutti i test correnti. Confrontando queste due analisi, si può facilmente vedere dove sono eventuali lacune. Cioè, aree di nuovo codice che sono state adeguatamente testate. In genere, questo viene fatto tracciando il codice utilizzando una forma di diagramma ad albero in cui il codice è diviso in blocchi funzionali, sotto ogni blocco sono le classi costituenti, sotto quelli sono i metodi e le funzioni reali. Ad ogni livello nella gerarchia, la dimensione relativa del blocco indica la quantità di codice. Sovrapponendo l’albero che mostra le modifiche al codice con l’albero che mostra lo stato corrente del test, è facile individuare le aree in cui manca la copertura del test.

Una mappa ad albero che mostra il codice invariato (grigio), rivisto/nuovo codice testato (verde), codice rivisto non testato (arancione) e nuovo codice non testato (rosso).

Perché potrebbe Test Gap Analysis materia nel processo di test?

In un articolo del 2013, i ricercatori dell’Università tecnica di Monaco hanno condotto uno studio per esaminare la correlazione tra codice nuovo, non testato e bug del software futuro. Hanno lavorato con Munich Re (una grande compagnia di assicurazioni), monitorando il loro sistema IT di lunga durata attraverso 2 versioni. Durante il rilascio, hanno stabilito quale codice era nuovo e hanno anche esaminato quale codice è stato testato e quale codice è stato rilasciato non testato. Successivamente, hanno monitorato il sistema per un lungo periodo e rintracciato tutti i bug segnalati alla fonte originale. Hanno scoperto due cose fondamentali. In primo luogo, circa un terzo di tutto il codice è stato rilasciato non testato. In secondo luogo, quando hanno tracciato i bug hanno scoperto complessivamente tra il 70 e l ‘ 80% di tutti i bug erano in codice non testato. Il grafico seguente mostra questo più chiaramente.

Come puoi vedere, il vecchio codice testato non aveva bug. Il nuovo codice testato aveva tra il 22 e il 30% dei bug e i bug rimanenti erano distribuiti in modo abbastanza uniforme tra il nuovo codice non testato e il vecchio codice non testato. Tuttavia, poiché il nuovo codice rappresentava solo il 15% del codice complessivo, è possibile vedere che il nuovo codice non testato rappresentava un numero sproporzionatamente elevato di bug.

Test Gap Analysis è progettato per identificare questo nuovo codice non testato. Tuttavia, può anche aiutarti in altri modi. Ad esempio, poiché monitora ciò che si sta testando, può identificare aree di codice esistente obsolete (ad esempio, sono ancora in fase di test, ma in realtà non vengono chiamate da alcun codice). Può anche evidenziare su quali aree è necessario concentrare le risorse di test. Eseguendolo regolarmente, i manager possono migliorare la pianificazione dei test, concentrandosi sul test del nuovo codice e cercando di garantire una copertura uniforme dei test.

Sviluppatori e tester allineati attraverso Test Gap Analysis

Test Gap Analysis è chiaramente un concetto potente. Ma è anche chiaro che non tutte le squadre ne trarranno ugualmente beneficio. I team che beneficeranno di più sono quelli che mantengono codebase di lunga durata con rilasci monolitici periodici. Nei codebase di lunga durata, gli sviluppatori lavorano spesso su codice scritto da altre persone. I tester possono fare affidamento su piani di test prodotti diverse versioni prima. Presi in combinazione, questi fattori possono significare che nessuno è abbastanza chiaro quale codice viene testato o come quel codice interagisce con altre parti del sistema. Qui, TGA può consentire ai tester di vedere esattamente quale codice è cambiato che consente loro di concentrarsi su questo. Possono anche identificare il codice nel sistema esistente che non è testato.

I team che utilizzano CI / CD possono anche beneficiare di questo approccio in quanto consentirà ai tester di identificare rapidamente esattamente quale codice viene modificato e quindi consentire loro di concentrarsi su questo. Può anche evitare il problema sopra menzionato in cui un pezzo di codice viene modificato subito dopo che è stato testato e quindi viene rilasciato con le modifiche non testate.

D’altra parte, i team che stanno lavorando su codice nuovo o di breve durata beneficeranno meno, poiché, per definizione, la maggior parte del codice non verrà testata all’inizio. Qui è importante utilizzare metodologie di test standard per garantire che il test sia buono. Potrebbe, tuttavia, essere utile per tali team iniziare a monitorare la copertura dei test utilizzando TGA poiché ciò consentirà loro di evitare problemi futuri.

Quali sono i potenziali problemi?

Ci sono alcuni problemi con TGA. Uno dei più grandi riguarda il fatto che non può dirti quale codice viene attivamente chiamato nella base di codice. Gli sviluppatori spesso aggiungono nuovo codice in preparazione per le versioni future, ma poiché questo è inattivo, la suite di test non può chiamarlo. Di conseguenza, questo codice verrà sempre visualizzato come nuovo codice non testato. Allo stesso modo, molte grandi basi di codice contengono blocchi di codice vecchio o orfano. Questi dovrebbero essere ripuliti periodicamente, ma ancora una volta questi distorceranno l’immagine per l’analisi del gap di prova.

Un’altra osservazione importante è che solo perché un pezzo di codice viene testato non preclude che il codice inneschi bug altrove. Alcuni dei peggiori bug sono quelli in cui un piccolo cambiamento in un pezzo di codice causa il fallimento di una funzione o di un metodo in un blocco di codice totalmente non correlato. Quindi, è fondamentale continuare a fare sia test esplorativi che test di regressione. Ciò che TGA può fare è identificare le aree nella base di codice esistente che non vengono testate correttamente durante il test di regressione.

Quali altre alternative aiutano a colmare il divario?

Test Gap analysis è sicuramente uno strumento utile per alcuni team. Tuttavia, ci sono altri modi per evitare una mancata corrispondenza tra ciò che i tuoi tester stanno testando e ciò che i tuoi programmatori stanno codificando. Un modo è quello di utilizzare un’automazione di test più intelligente che sia in grado di identificare dove e quando le cose sono cambiate, sia sul frontend ma anche, soprattutto, nel backend. Qui a Functionize, i nostri test utilizzano impronte digitali intelligenti accoppiate con apprendimento automatico e auto-guarigione per ridurre la manutenzione dei test. Ciò consente ai test di adattarsi in modo proattivo alle modifiche del frontend e di monitorare cose come le chiamate al server, i tempi di risposta e se i pulsanti/funzioni sono effettivamente visibili. Ciò significa che i tuoi tester non verranno scoperti dalle modifiche apportate al codice backend o alle modifiche al design/CSS che alterano il layout del frontend.

Il nostro sistema intelligente può anche creare test monitorando come gli utenti interagiscono con il sistema. Questo aiuta a garantire che ci siano meno lacune nella copertura del test. Uno dei nostri strumenti più recenti ti consente di scrivere nuovi test in inglese semplice. Questi vengono analizzati dal nostro strumento di elaborazione del linguaggio naturale e convertiti in test utilizzabili. Ciò significa che durante lo sviluppo, gli sviluppatori possono semplicemente specificare cosa dovrà essere testato usando l’inglese normale, chiudendo così ulteriormente il divario tra le due discipline.

Conclusioni

Test Gap Analysis ti aiuta a identificare quale codice viene rilasciato non testato e quindi può aiutarti a focalizzare le risorse di test in modo più efficace. Non sorprende, si scopre che il codice non testato è molto più probabile che contenga bug e quindi qualsiasi strumento che possa aiutare a garantire che questo codice sia testato correttamente è utile. Tuttavia, come abbiamo visto, TGA può solo integrare le migliori pratiche esistenti. È fondamentale per mantenere il vostro test di regressione e test esplorativi. Molti dei vantaggi di TGA possono essere raggiunti anche utilizzando strumenti di test intelligenti. Ma nel complesso, la cosa principale da evitare è isolare il tuo team di test dal lavoro dei tuoi sviluppatori. Per citare erroneamente un vecchio adagio, dovresti assicurarti che la mano sinistra sappia cosa sta facendo la mano destra!