I test funzionali, nell’ambito del più ampio Sdlm (Software Development Lifecycle Management), rappresentano il primo step per la garanzia della qualità del software, perché consentono di verificare non solo che l'applicazione funzioni come previsto sul fronte tecnologico ma, soprattutto, che faccia ciò che gli utenti effettivamente si aspettano rispetto alle loro richieste iniziali.
I test funzionali, di fatto, rendono conto delle esigenze degli utenti, danno agli sviluppatori la certezza che i processi di business rispettino tali esigenze e consentono ai team di Qa (Quality Assurance), di verificare che il software sia effettivamente pronto per il rilascio in produzione.
Tale premessa è doverosa dato che si riscontrano ancora alcune lacune rispetto a questo tipo di attività, spesso confusa con i cosiddetti unit test. Questi ultimi servono a verificare se il codice consente di effettuare nel modo corretto le cose per cui è stato scritto; i test funzionali sono complementari, ma molto diversi rispetto a quelli unitari perché indicano se l'applicazione ultimata offre le funzionalità volute (viste dalla prospettiva dell'utente finale e del processo di business). Assumono quindi un ruolo determinante rispetto alla strategia, agli obiettivi e alle esigenze del business.
Sebbene abbiano una funzione cruciale sul fronte della qualità del software e, quindi, del servizio applicativo reso al business, i test funzionali non dovrebbero comunque richiedere attività di lunga durata, costose o con un eccessivo dispiego di skill. Una delle possibili soluzioni viene dall’automazione dei test funzionali anche se, a volte, può risultare utile anche il testing manuale.
In linea di massima, i processi di test manuali richiedono un’esecuzione troppo lunga per le esigenze di business (data la carenza di risorse It unita ai tempi stretti di rilascio), offrono una copertura incompleta (la proliferazione di piattaforme, sistemi operativi, dispositivi client, processi di business e set di dati mandano in tilt i processi di test manuali) e comportano un maggior livello di rischio derivante dagli errori umani.
Tuttavia, in alcuni ambienti, i test manuali possono rappresentare la scelta giusta. Ad esempio, possono essere indicati per le applicazioni in fase di sviluppo, che cambiano spesso Ui (user interface) o logica e che sono sviluppate sulla base di tecnologie non supportate o toolkit Ui sviluppati internamente, oppure per attività di livello più basso quali le verifiche a livello di sistema.
Esclusi dunque alcuni casi come quelli citati, l'automazione diventa sempre più essenziale per migliorare la velocità, l'accuratezza e la flessibilità del processo di testing del software, perché consente di individuare e risolvere più precocemente un maggiore numero di difetti.
Perché scegliere l’automazione
Le organizzazioni It di qualsiasi tipologia di azienda sono oggi alle prese con una moltiplicazione dei progetti di sviluppo di applicazioni con, al contempo, una contrazione dei tempi di rilascio, cui non sempre corrisponde un aumento del budget o delle risorse. Uno scenario ancor più sfidante se pensiamo che le imprese si affidano a infrastrutture di elaborazione ormai molto complesse. Una normale organizzazione può dipendere da una serie di applicazioni sviluppate per funzionare su sistemi operativi diversi, che utilizzano client di front-end differenti, coinvolgono numerosi processi di business e interagiscono con molti set di dati separati. Testare tutte le possibili permutazioni di questi componenti crea una situazione di elevata complessità, con centinaia o migliaia di scenari di test.
Eventuali errori del software possono costare molto cari, in termini di vendite perse, improduttività dei dipendenti, insoddisfazione dei clienti, ma anche demoralizzazione dei team di sviluppo e Qa. Inoltre, tanto più avanzata è la fase di sviluppo in cui i difetti vengono individuati, tanto più questi risultano costosi da correggere (“Correggere un difetto rilevato in ambiente di produzione può costare oltre 100 volte di più che risolverlo tempestivamente già in fase di progettazione” riporta Hp nel white paper ‘Best practice per implementare soluzioni per i test funzionali automatizzati’).
La strada dell’automazione, solitamente, consente di ridurre i rischi di inefficienza e inefficacia delle soluzioni; garantendo una copertura più ampia, i test funzionali automatizzati riducono il rischio di errori in produzione e migliorano il Roi.
E la decisione di automatizzare o meno il processo di test dovrebbe essere basata proprio su criteri di Roi. In generale, il ritorno è positivo quando l'applicazione richiede test di regressione, comporta molteplici attività di creazione/patching/correzione, deve essere testata su numerose configurazioni hardware o software e supporta un ampio numero di utenti. Tuttavia, l'automazione risulta economicamente conveniente anche quando sono coinvolte attività ripetitive quali il caricamento di dati o la configurazione di sistemi o se l'applicazione deve soddisfare uno specifico Sla. Di contro, non è indicata quando si testa l'usabilità di un'interfaccia utente (Ui), si conducono test esplorativi o quando le applicazioni non sono ancora mature.
Tuttavia, quando si valutano i potenziali benefici dell'automazione, è importante considerare anche i benefici intangibili, come il morale più alto e la maggiore soddisfazione dei tester, la maggiore soddisfazione e fidelizzazione dei clienti e la migliore reputazione in termini di affidabilità del software tra gli utenti finali.
In linea generale, alcuni dei vantaggi derivanti dall’automazione del testing funzionale si possono riassumere in:
– accelerazione dell'esecuzione: i computer sono molto più veloci degli umani nell'eseguire gli script di testing funzionale, il che permette di condurre più test in meno tempo, testare più applicazioni in un dato periodo e rilasciare un maggior numero di progetti;
– copertura di test maggiore: i prodotti di testing funzionale automatizzati supportano l'esecuzione degli script di test per tutti i browser, i sistemi operativi e gli altri contesti più comuni. Con gli strumenti automatizzati, i test di regressione per applicazioni e ambienti che cambiano continuamente risultano più facili che con i processi manuali. Inoltre l’automazione dei processi di testing consente di eseguire calcoli, manipolare set di dati e creare rapidamente iterazioni multiple dei test per espandere la copertura dei test case (con gli strumenti di test automatizzati è possibile emulare rapidamente qualunque mix di transazioni e qualsiasi workload utente);
– accuratezza e rilevamento più precoce dei difetti: gli sviluppatori riescono a replicare e documentare i difetti del software in modo più rapido ed efficace, contribuendo così a sveltire i processi di sviluppo e verificando, al contempo, la corretta funzionalità su tutti gli ambienti, i set di dati e i processi di business;
– definizione di processi formalizzati: l’automazione incoraggia i team di collaudo a formalizzare i propri processi, il che conduce a una maggiore coerenza delle attività e a una migliore documentazione;
– maggiore riutilizzabilità dei test: una volta definiti gli script gli sviluppatori potranno usare, riusare e integrare la suite di test via via che apportano modifiche alle proprie applicazioni.
Best practice da ricordare
Anche quando la convenienza economica di automatizzare un’attività di test appare del tutto evidente, può comunque essere difficile determinare il modo migliore per affrontare la transizione al processo automatizzato. Hp suggerisce allora una checklist di best practice per implementare processi automatizzati di testing del software che risultino realmente efficaci rispetto alle specifiche necessità aziendali.
1) Redigere un documento con il piano del test. Comprendere le finalità dell'applicazione da testare è essenziale per il successo dell'attività; per questo è fondamentale svolgere una preliminare pianificazione che serva ad assicurare che i requisiti di test siano implementati correttamente.
2) Suddividere i test in ‘test case’ da automatizzare. Con ogni probabilità, nelle aziende non sempre risulterà possibile automatizzare tutti gli aspetti delineati dal piano di test. Per questa ragione, i test automatizzati dovrebbero concentrarsi sui complessi processi di business essenziali, associati alle funzionalità dell'applicazione e per i quali sono stati progettati in base ai requisiti.
3) Creare i test automatizzati. Sfruttare cioè le tecnologie oggi disponibili per creare i test senza dover compiere attività di scripting (esistono in commercio tool capaci di rilevare il processo di business per l'applicazione target e permettere agli utenti di creare flussi di test che in seguito potranno essere salvati e riutilizzati).
4) Espandere la copertura del testing usando funzionalità integrate per le tabelle dati: i tester possono così creare test data-dependent che utilizzano specifiche parole chiave memorizzate su fogli elettronici per popolare i campi in un’applicazione. Questa capacità permette ai collaudatori di far passare enormi volumi di dati di test attraverso l’applicazione.
5) Aggiungere verifiche ai test. I criteri effettivi che decretano il successo o l’insuccesso di un test dovrebbero essere aggiunti ai test automatizzati (per poter così effettuare delle verifiche continue alle fasi di test). I criteri comprendono verifiche del front-end dell'applicazione, del middle tier o del database di back-end. La verifica integrata del database conferma i valori registrati al suo interno e controlla l'accuratezza delle transazioni e l'integrità dei dati dei record che sono stati aggiornati, cancellati o aggiunti.
