Affrontiamo in questo articolo uno dei punti focali dell’attività di test: la non regressione.
Oltre a garantire che una funzionalità sia resa disponibile con una percentuale di errore ragionevolmente bassa in linea con gli standard aziendali e rispetti le specifiche richieste dal cliente, è altrettanto importante garantire che non esistano “interferenze” in altri contesti. Queste interferenze vengono chiamate regressioni.
Ma cos’è esattamente una regressione?
La regressione è un effetto indesiderato, un passo indietro implicito o esplicito, determinato dall’introduzione di una specifica funzione.
Il test del software accentua la sensibilità verso la regressione e il team che se ne occupa ne certifica ufficialmente l’assenza. Per usare un esempio comprensibile a tutti, pensiamo a una caccia al tesoro: il tester è colui che con maggiore astuzia rispetto agli altri deve trovare l’oggetto nascosto, percorrendo un percorso pieno di birilli senza farne cadere nemmeno uno. L’immagine rende perfettamente l’idea: l’oggetto nascosto è la regressione, il problema che non ti aspetti, la buca nascosta lungo il percorso. Il percorso ha dei birilli che rappresentano le funzionalità passate e già in uso da parte dell’utilizzatore finale: questi birilli non devono cadere nonostante le buche in altri punti del terreno.
Compito del tester è cercare le regressioni e saper riconoscere se queste vanno eliminate del tutto o tollerate (perché magari la loro dimensione è minima) con l’obiettivo finale di non fare crollare birilli (le funzionalità) e terreno sottostante (la struttura portante del programma).
Come e perché si originano le regressioni?
In due modi principalmente:
1) in modo diretto quando si introduce una funzionalità con caratteristiche nuove o che utilizza DLL più evolute. In questo caso, soprattutto quando si utilizza una componentistica più recente, si manifesta ciò che in termine tecnico viene chiamata rottura di compatibilità: il componente (che al suo interno ha logiche proprie, calcoli o metodi di reperimento dati) non può essere più compatibile con i rilasci precedenti e quindi il suo rilascio non può essere differito rispetto alla funzionalità asservita.
2) in modo indiretto. In questo caso, la funzionalità in fase di verifica non ha apparentemente nessun malfunzionamento, ma è possibile che vi siano degli impatti in altri punti della stessa funzione o in altre funzioni parallele.
Le verifiche di non regressione necessitano di un piano di test distinto rispetto a quelli tradizionali, che deve contemperare allo stesso tempo due esigenze normalmente parallele:
- assenza di anomalie estetiche e funzionali;
- assenza di perdite di performance nella gestione dei dati o di sopportazione dei picchi di carico.
A seconda degli impatti previsti o prevedibili, il tester dovrà affinare la sua metodologia di indagine, in modo da minimizzare gli effetti in termini di tempo e puntualità di risposta. Nel fare questo dovrà ovviamente tenere conto del tipo di regressione sospettata (diretta o indiretta) e del suo impatto (limitato, esteso, invasivo).
Di cosa tener conto durante i test di non regressione?
Nell’applicazione pratica della non regressione occorre tenere conto dei seguenti aspetti:
- un impatto esteso o invasivo giustifica sempre un rinvio della data di deploy, se non esiste un numero congruo di giorni “polmone” o se esso è palesemente insufficiente.
- Controlli di non regressione vanno sempre effettuati in occasione della produzione di dvd fisici oppure di immagini ISO equivalenti.
- Controlli di non regressione vanno sempre effettuati quando l’architettura sottostante al programma o la parte architetturale su cui poggia il programma (splash di presentazione, DLL di avvio e di comunicazione ad esempio) subisce un’evoluzione o una rottura di compatibilità.
- Controlli di non regressione vanno effettuati sempre quando un’architettura adottata su una famiglia di prodotti viene riutilizzata (adattandola o migliorandola) a un prodotto nuovo della stessa famiglia o di altre linee di mercato.
Concludiamo citando alcuni contesti tecnologici dove è fondamentale attuare il test di non regressione. Come possiamo facilmente dedurre sono necessari test negli ambienti di produzione in cui si esaminano in forma aggregata dati di notevole quantità (banche, assicurazioni), quelli in cui la mole di dati rappresenta la base per dedurre dei metodi matematici atti a ricavarne altri (nel mondo borsistico ad esempio si pensi alle simulazioni matematiche atte a dedurre un metodo numerico utilizzato nel pricing di un titolo oppure alle rilevazioni statistiche) o quelli in cui il dato rappresenta la base di partenza per assicurare condizioni di assoluta coerenza nei settori life critical del farmaceutico, automotive e avionico-spaziale.
Tutto questo per ribadire ancora una volta come il tester sia una figura a tutto tondo che guarda al passato (i programmi esistenti), al presente (la funzionalità attuale in verifica) e anche al futuro (in termini di collaborazione con altre aree aziendali per garantire che le prossime implementazioni non abbiano difetti).
Articoli correlati
Leggi l’articolo successivo sulla tempificazione e valutazione del rischio.
Corsi correlati
Vai alla pagina del nostro corso di introduzione a SQL e ai database relazionali.