Il test di non regressione

test di non regressione

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?

E un effetto indesiderato, un passo indietro implicito o esplicito, determinato dalla introduzione di una specifica funzione. Questo aspetto viene ovviamente previsto già a monte nel ciclo del software e lo sviluppo stesso deve nei moderni contesti agile tendere a minimizzare il rischio.

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 ad una caccia al tesoro: il tester tecnico prima e applicativo poi è 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 buche 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.

Tenendo conto che le DLL sono richiamate trasversalmente da funzionalità fra loro anche completamente diverse, è implicito controllare che non esistano regressioni.

 

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).

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) ad un prodotto nuovo della stessa famiglia o di altre linee di mercato.

 

Da ultimo precisiamo meglio il contesto in cui nel contesto tecnologico attuale è fondamentale attuare il test di non regressione.

Come possiamo facilmente dedurre non sono ammesse regressioni sull’esistente 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) e 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.

Non da ultimo, infine, il mondo web e e-commerce in cui gli accessi in un tempo definito, possono essere anche milioni in contemporanea.

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).

Diventare un tester quindi è un’occasione moderna e tangibile, da non lasciarsi scappare!