Articolo del Mese - Giugno 2012

I test di regressione in ambienti legacy

by Randy Rice

Una grande quantità di codice residente in sistemi complessi, non documentati. È una situazione che corrisponde a quella esistente in molte organizzazioni. Si è portati a credere che la percentuale più grande degli investimenti ICT vada nella direzione di nuove tecnologie. L'amara verità è, invece, che la gran parte dei soldi viene spesa per manutenere i sistemi più vecchi, quelli cosiddetti legacy, ovvero quelli che sono frutto dell'eredità del passato. Sistemi che sono tuttora organici alle necessità aziendali, ma che sono cresciuti in modo disorganizzato e non pianificato. Di fatto, dietro questi sistemi, il cui codice è continuato a crescere nel tempo, esistono funzionalità e difetti di cui nessuno è ormai a conoscenza.
Chiunque abbia lavorato nell'area della manutenzione del software sa che non è semplice mettere le mani nel codice sviluppato da altri e comprenderne il significato. A prima vista può sembrare che sia dedicato a svolgere una determinata funzione mentre, a causa di porzioni di codice cui si relaziona, l'effetto è diverso. Ciò significa che per comprendere la vera complessità del sistema è necessario affrontare un'analisi estesa, mirata a tutte le componenti del sistema: il codice, ovviamente, l'hardware, le interfacce con altri sistemi, i dati, le procedure, le persone stesse che operano su quel sistema.
L'ideale sarebbe riuscire ad avere disponibile una documentazione accurata e aggiornata. Ma ciò accade di rado.
L'esperienza ci insegna che anche la più piccola delle modifiche può dare luogo a un'infinita serie di conseguenze su tutte le componenti che sono interessate al sistema in oggetto. Per le persone addette al collaudo del software questo significa dover sempre accertarsi che le modifiche siano state fatte correttamente così come accertarsi che esse non abbiano causato effetti collaterali, non pianificati, sulle componenti associate. Questo tipo di attività è nota come test di conferma e test di regressione.
Nel test di regressione è importante sapere il numero di prove (test case) necessarie per collaudare una nuova release di software. Ciò dipende da:
Il livello di rischio del sistema da collaudare – Se l'effetto potenziale di difetti è minimo, è inopportuno eseguire un gran numero di test per ogni modifica effettuata. Tuttavia, se davvero sussistono dei rischi reali, è bene procedere con un gran numero di prove.
Il livello di integrazione del sistema – Questa è una lama a doppio taglio. Da una parte si ritiene che i sistemi altamente integrati richiedano test di regressione a causa della loro complessità e del gran numero di interfacce presenti (un cambiamento in un modulo potrebbe scatenare un difetto all'interno del flusso procedurale); dall'altra questi sistemi si prestano con molta difficoltà a essere sottoposti a test di regressione in quanto dovrebbero essere implementate un gran numero di prove per riuscire davvero a coprire l'intera dimensione ed estensione del sistema. Se fossimo nella condizione di poter prevedere quali potrebbero essere gli errori non vi sarebbe necessità di eseguire dei test di regressione. Ma questo non è quanto mediamente si verifica con la maggior parte dei sistemi.
La dimensione del cambiamento – Anche questo aspetto è difficile da determinare. Si è spesso tentati a ridurre il livello dei test di regressione in presenza di piccole modifiche. Tuttavia l'esperienza ci dice che alcuni dei problemi maggiori sono spesso causati da singoli, piccoli cambiamenti.
Le risorse disponibili per eseguire test di regressione – Ovvero tempo, persone e strumenti. Può capitare di accorgersi della necessità di eseguire un certo numero di test di regressione, ma essere limitati in questo dalla scarsità di risorse disponibili. È un qualcosa che ha a che fare con il test management. Le persone possono fare il loro lavoro solo se hanno a disposizione risorse adeguate. In assenza di strumenti di automation, i test di regressione possono risultare poco precisi e, allo tesso tempo, laboriosi. Sebbene un'attività di questo tipo, abitualmente definita come pseudo regression testing, possa apparire adeguata, non consente di effettuare un autentico test di regressione.

Due importanti domande
Gli aspetti di integrazione e interoperabilità comportano un'attività di testing di regressione molto complessa e dare risposta a semplici domande, quali cosa collaudiamo e quanto collaudiamo, risulta spesso difficile. L'approccio che descrivo nel seguito si è dimostrato adeguato in molti dei progetti in cui sono stato coinvolto.

Esempio
Ipotizziamo di avere quattro sistemi distinti, ciascuno con un certo numero di servizi e componenti. Il nostro obiettivo è eseguire un test di regressione ogni qualvolta venga apportata una modifica, anche piccola, a un servizio di un determinato sistema. La domanda è: “Cosa deve essere testato?”
Sappiamo che esiste un certo grado di integrazione, ma non sappiamo esattamente quale. È vero, esiste un'integrazione tra i quattro sistemi, ma siamo a conoscenza soltanto degli aspetti di integrazione che esistono tra soli due sistemi. Quando il sistema viene utilizzato, tutto sembra tranquillo, ma utilizzando un terzo sistema viene riscontrato un errore.
Un altro aspetto di questo problema è la mancanza di sufficiente documentazione tecnica. E questa situazione fa sì che non si possano condurre dei test di rilevante importanza. Il problema diventa ancor più complesso quando viene presa in considerazione l'integrazione tra tutti i sistemi. È una situazione che crea grandi difficoltà poiché questo tipo di interazioni può richiedere l'esecuzione di un numero elevatissimo di test.
E allora, che fare? Ecco due soluzioni che si sono rivelate valide in alcuni dei progetti in cui sono stato coinvolto.

Opzione 1
Un primo approccio prevede attività di testing che mette in gioco più componenti del sistema. Ciascuna porzione del test mette in esercizio molteplici funzioni in ciascun singolo sistema. Più porzioni di test vengono messe in esecuzione, maggiore sarà il numero di errori potenzialmente riscontrabili. La natura di questi test è di tipo random, per cui alcuni difetti potrebbero non essere rilevati.
Di solito non si hanno poi tempo e risorse sufficienti per eseguire un grande numero di test. Diventa pertanto importante, se non essenziale, avvalersi di strumenti di automazione. In caso contrario si deve intervenire di persona per cercare di stabilire il numero corretto di prove che devono essere determinate per soddisfare gli obiettivi.
Vi sono altre utili tecniche che possono essere considerate. Per esempio attività di testing di tipo pairwise, efficienti soprattutto per testare le interazioni tra due funzioni correlate. Tuttavia, esiste un approccio ancora più efficiente per eseguire test su interazioni di sistemi complessi, ed è quanto descritto nell'Opzione 2.

Opzione 2
Un metodo che funziona molto bene consiste nel non considerare in prima battuta gli aspetti di integrazione tecnica, ma focalizzarsi sull'integrazione business funzionale come definita dai processi di workflow. A differenza dell'integrazione tecnica, l'integrazione a livello di workflow permette di avere una migliore comprensione da parte delle persone che utilizzano il sistema e permette di operare un test rappresentativo della reale operatività che ha luogo su più sistemi. Non solo, seguendo il workflow di sistema si riesce anche ad avere una mappatura dell'integrazione tecnica.
Con questo approccio si possono creare test di regressione rappresentativi delle attività business più importanti. Si ottiene così un alto livello di copertura dei più importanti processi di workflow senza dover avviare attività di testing su funzionalità a bassa criticità.
Un ulteriore vantaggio di un approccio basato sul workflow consiste nel poter creare i test con più facilità poiché gli scenari funzionali sono ben compresi dagli esperti in materia. Agli scenari funzionali possono poi essere applicate delle priorità in termini di rischio, cosa che permette di utilizzare al meglio tempo e risorse soprattutto in situazioni dove queste sono limitate.

Conclusioni
Non esiste la soluzione perfetta per risolvere i problemi legati ad attività di testing di regressione in sistemi legacy complessi e mal documentati. A ogni modo intervenendo sui processi di workflow attraverso strumenti di test automation è spesso possibile ottenere ottimi risultati.