(articolo redatto da Fiore Braciglianese)
Continua il nostro ciclo di articoli di approfondimento dedicati al software testing.
Dopo aver visto come applicare una combinazione di strategie di software testing per migliorare la qualità in un processo di sviluppo software, in questo articolo vogliamo mostrare come sia possibile implementare una strategia di test di non-regressione, combinando test manuali e test automatizzati a uno o più livelli.
Introduzione
In molti contesti internazionali, l’attenzione dedicata ai feedback degli utenti è considerata strategica per il business di un’organizzazione. I rilasci in produzione, spesso dovuti alla continua modifica dei requisiti, vengono effettuati frequentemente per accelerare il time-to-market e migliorare la customer-experience.
Nei cicli di vita iterativi, il rischio di regressioni tende ad essere più elevato rispetto ai modelli sequenziali. Questo comporta la necessità di adottare pratiche comuni di test per mitigare il rischio associato a tali vulnerabilità. Un approccio strategico è quello di combinare test manuali e test automatizzati da eseguire in modo continuo prima di ogni rilascio in produzione.
I test automatici, generalmente inseriti nelle pipeline di un processo di CI/CD (Continous Integration/Continous Delivery), consentono di eseguire batterie di test complete in modo ripetitivo ogni qualvolta viene creata una nuova build o ad ogni commit del codice. I test manuali, invece, si concentrano su attività più critiche e possono focalizzarsi su quei casi d’uso particolari che potrebbero essere impattati da potenziali regressioni.
In questo articolo vogliamo mostrare come sia possibile implementare una strategia di test di non-regressione combinando test manuali e test automatizzati a uno o più livelli. Il Test Manager ha il compito di scegliere e adattare le strategie di test più appropriate, monitorando il processo ed intervenendo, in caso di necessità, con opportune azioni correttive, svolgendo un ruolo cruciale nella gestione efficace del rischio di regressioni.
Test Strategy: Regression-Averse & Test Automation
Le strategie di test di non-regressione (Regression-Averse) e di automazione (Test Automation) sono approcci comuni in un processo di quality assurance (QA). Tali strategie utilizzano metodologie e tecniche per individuare eventuali regressioni che altrimenti potrebbero presentarsi in ambiente di produzione generando impatti negativi sul business.
L’automazione dei test consente di verificare velocemente che le modifiche apportate al software non abbiano generato effetti indesiderati alle funzionalità esistenti.
I test manuali possono richiedere più tempo rispetto ai test automatici, ma effettuano un controllo dettagliato nell’individuare problemi che invece potrebbero sfuggire a un test automatizzato.
Una componente significativa dei test manuali sono i test basati sull’esperienza, noti come “ad-hoc testing” o “exploratory testing”. Questa tipologia di test usa l’esperienza, le competenze e le conoscenze di dominio dei tester, per scoprire difetti che altrimenti potrebbero non emergere attraverso un approccio più tradizionale basato sui requisiti. La combinazione di tali componenti può fornire una copertura completa nella ricerca di potenziali regressioni prima del rilascio in produzione.
Uno studio del NIST (National Institute of Standards and Technology), “The Economic Impacts of Inadequate Infrastructure for Software Testing“, pubblicato nel 2002, ha analizzato i costi associati alla correzione dei difetti intercettati nelle varie fasi del ciclo di vita dello sviluppo software.
In tale report si evince (fig. 1.1) come il costo associato alla correzione di un defect in produzione sia notevolmente maggiore rispetto a quello richiesto nel caso in cui lo stesso defect dovesse essere intercettato nelle fasi di sviluppo o di collaudo.
Quindi, attuare una strategia di non-regressione fin dalle prime fasi di sviluppo è di fondamentale importanza per individuare i difetti nelle fasi che precedono i rilasci.
Investire nella progettazione e nell’implementazione di una adeguata infrastruttura di test può generare enormi benefici in termini di risparmio di tempo, energie, risorse economiche, contribuendo ad aumentare la qualità del software.
Il Paradosso Pesticida: problemi e soluzioni nelle Strategie di Test di non-regressione/h2>
Uno dei principi fondamentali del testing è il “paradosso pesticida”, secondo cui, se gli stessi test vengono eseguiti ripetutamente, è presumibile che ad un certo punto non rilevino più difetti (questo concetto prende spunto dall’analogia con l’uso eccessivo di pesticidi in agricoltura, che porta alla resistenza degli insetti e alla perdita di efficacia dei pesticidi stessi nel tempo).
In una strategia di non-regressione è importante analizzare periodicamente i prodotti di lavoro per mantenerli aggiornati ed avere costantemente una copertura completa dei requisiti. Di seguito riportiamo alcuni problemi e le possibili soluzioni per attenuare gli effetti del paradosso pesticida sui test di non-regressione.
Problemi:
- Test Obsoleti: I test potrebbero diventare obsoleti durante l’evoluzione del software e gli scenari di test non garantire più copertura delle funzionalità critiche, lasciando spazio a potenziali regressioni che potrebbero non essere più intercettate in fase di collaudo.
- Falsi Negativi: I test potrebbero dare continuamente risultati positivi, sviluppando la falsa credenza e la sicurezza di un software stabile. Questo potrebbe portare ad un impiego non efficace delle risorse e ad uno spreco di energie nell’eseguire casi di test non più rilevanti.
- Problemi di Manutenzione: Nel medio e lungo periodo i test obsoleti potrebbero non riflettere più il comportamento attuale del software diventando incoerenti o non rappresentativi delle attuali funzionalità, diventando difficili da manutenere e aumentando il rischio di regressioni.
Soluzioni:
- Comunicazione efficace: Favorire la collaborazione tra i vari team. Gli analisti del test possono dare supporto nell’identificare casi di test da aggiornare o inserire in una più ampia strategia di non-regressione. Il team di sviluppo può contribuire a realizzare codice facilmente testabile ed a supportare i tester nell’ automatizzazione degli scenari critici.
- Diversa Prospettiva: Adottare approcci come il turn-over dei tester nel team può aiutare ad avere una diversa prospettiva, più critica, sugli scenari da aggiornare e da eseguire. Inoltre, l’utilizzo di pre-condition e parametri di input dinamici nei test automatici consente di coprire una più ampia gamma di scenari di test.
- Test Driven Development: Adottare l’approccio TDD, una pratica di sviluppo che promuove la scrittura dei test prima dell’implementazione del codice effettivo, può garantisce che i test siano sempre allineati alle nuove funzionalità e che vengano puntualmente aggiornati quando cambiano i requisiti.
Ovviamente la formazione continua è una componente fondamentale per assicurare che il team di test acquisisca le competenze necessarie per implementare strategie di test efficaci. La consapevolezza dei rischi legati al paradosso pesticida nei test di non-regressione consente di adottare misure correttive quando servono. La comprensione di nuove pratiche di test può facilitare la collaborazione tra i membri del team, acquisire strumenti e tecniche di automazione per garantire che i test siano ben progettati, efficaci ed efficienti.
Conclusioni
L’utilizzo di strategie di test di non-regressione, insieme a pratiche di test per mitigare gli effetti del paradosso pesticida, offre notevoli vantaggi nell’assicurare la qualità del software.
Tali strategie consentono di individuare rapidamente eventuali anomalie e garantiscono che una modifica alle funzionalità non generino effetti indesiderati sulle funzionalità esistenti. Per massimizzare i benefici e scongiurare il rischio di regressioni, è fondamentale effettuare continue revisioni ai prodotti di lavoro, mantenendo i test costantemente aggiornati. In questo modo, si può garantire che il software soddisfi standard di qualità attesi, riducendo costi e rischi associati a regressioni in produzione.
Se anche tu vuoi occuparti di progetti di Software Testing
dai un’occhiata alle nostre opportunità di lavoro e conosciamoci subito!
