Differerenza tra manual e automated testing, scripting e data driven testing

I compromessi del testing

In un contesto aziendale realistico non è pensabile investire risorse infinite nel testing, molto spesso, si stabilisce una soglia accettabile di copertura si mette a punto una strategia che consenta di raggiungerla nel modo più economico possibile in termini di tempo e risorse. Di seguito saranno analizzate alcune delle principali scelte da operare durante la fase di progettazione dei test presentandone vantaggi, svantaggi e combinazioni ideali. Tali scelte sono spesso dettate da trade-off economici o da valutazioni realistiche sulla natura e sul target dell’applicazione oggetto di test.

Emulatori vs Real Device

Come già detto in un altro articolo sulla Mobile Testing Challenge, la varietà di dispositivi mobili costituisca un limite per il testing.

Testare su dispositivi reali ha il vantaggio di consentire di analizzare tute le limitazioni e gli imprevisti dovuti all’hardware e al software che i clienti andranno effettivamente ad utilizzare. Ovviamente un approccio orientato a testare sul maggior numero possibile di dispositivi reali si rivelerebbe estremamente dispendioso, non solo bisognerebbe acquistare un gran numero di device ma sarebbe necessario anche dotarli di una connessione dati e telefonica. L’enorme offerta di applicazioni non rende vantaggioso per produttori e operatori telefonici offrire un noleggio agevolato o il prestito a scopo di test. Tutto ciò a discapito delle realtà aziendali più piccole. Senza contare che sarebbe complesso gestire un magazzino con centinaia di dispositivi e senza una solido protocollo per la produzione, collezione e analisi dei risultati il testing su device finirebbe per diventare disorganizzato e laborioso. La soluzione ideale per chi sceglie questa strada è individuare un subset di dispositivi che ricoprano le principali categorie target e che godano di un’ampia diffusione. Salvo esigenze specifiche è buona regola evitare di testare su device fuori produzione o con software non più supportato per non incorrere in aumenti esponenziali dei costi.

Dall’altra parte della barricata troviamo gli emulatori, estremamente più economici e di facile gestione. E’ sufficiente scaricare il profilo di un nuovo device, messo a disposizione gratis dai produttori, per avere istantaneamente una replica fedele sulla quale testare la compatibilità del prodotto. Poiché l’emulatore nasce proprio allo scopo di agevolare il testing esso è dotato di meccanismi per una diagnostica dettagliata e la raccolta di log ed errori.

Il risparmio deriva dal fatto che una sola piattaforma, se aggiornata frequentemente, consente di far girare l’applicazione su ogni nuovo device presentato sul mercato.

Nonostante questi aspetti positivi gli svantaggi sono numerosi: non è possibile emulare la varietà di hardware faults e interruzioni a cui un dispositivo reale andrà incontro durante l’utilizzo, non è possibile avere un’immagine precisa al pixel della GUI sullo schermo, non è possibile effettuare analisi sulle performance in quanto le risorse sono dipendenti da quelle del sistema che ospita l’emulatore, infine non è possibile testare le interazioni con l’ambiente circostante che potrebbero avere influenza sul dispositivo.

In sintesi è possibile affermare che l’emulatore è ideale per le prime fasi del testing in cui è necessario ancora individuare defect di tipo funzionale e grafico mentre per test più sofisticati, ad esempio prestazionali e operazionali, è necessario prevedere sessioni di test su dispositivi reali.

Cloud solutions

Una soluzione che consente di testare su un gran numero di dispositivi reali pur godendo di tutti i vantaggi di un emulatore è affidarsi ad un provider di servizi cloud.

Questi provider mettono a disposizione un gran numero di dispositivi reali dotati di un’unità di controllo che consente di utilizzarli da remoto attraverso applicazioni web. In tal modo è possibile riprodurre la pressione di un pulsante, raccogliere screenshot ed utilizzare la tastiera vedendo live quello che succede sul dispositivo.

La responsabilità dei provider è garantire una copertura sufficiente per gli aspetti più critici del testing come la diversità dei device, la localizzazione e la riproduzione di scenari utente come la ricezione di una chiamata o di un SMS. Il tutto fornendo dati di diagnostica e log per consentire l’analisi delle performance oltre che del funzionamento. Spesso è il cliente a definire gli indicatori e i parametri vitali del sistema che desidera tenere sotto controllo durante l’esecuzione dei test.

Il costo di questa soluzione è notevole ma ridotto rispetto all’acquisto di un gran numero di device, inoltre il cloud è condiviso con altri utenti e pertanto si paga soltanto il tempo di testing effettivo sui device di interesse.

Manual vs Automated testing

Esistono numerosi modi di progettare ed eseguire il testing di un’applicazione mobile e molto spesso nessuno di essi può essere definito completamente giusto o sbagliato. Uno dei trade-off che le aziende si trovano a valutare più frequentemente è la scelta tra l’esecuzione manuale ed automatica dei test pianificati.

Un primo vantaggio rilevabile nell’utilizzo di test automatici è la velocità di esecuzione e la loro infinita ripetibilità. Anche la compatibilità del test tra i vari device target è garantita dai numerosi framework, open source ed a pagamento, che, se l’organizzazione è efficiente, consentono agli sviluppatori stessi o al QA team di produrre a basso costo i test necessari.

Uno svantaggio insito nella scrittura di test automatici è la possibilità di introdurre dei bug nel test stesso, tuttavia garantisce di testare tutto quello che si desidera nel modo che si desidera ed è un buon approccio se il team è in grado di utilizzare linguaggi di programmazione e quindi di adattare gli script prodotti ai cambiamenti dell’applicazione. Purtroppo produrre manualmente il test è un’operazione che ha tempi di startup molto lunghi e che risulta inizialmente dispendiosa in quanto richiede personale in grado di programmare e bisogna prevedere la manutenzione dei test man mano che l’applicazione si evolve.

Questi costi iniziali vengono però assorbiti all’aumentare del numero di esecuzioni del test prodotti, traducendosi al superamento di una certa soglia in un netto risparmio.

Le esecuzioni multiple effettuate da una macchina sono inoltre prive della percentuale di errore umano che un tester introdurrebbe eseguendo numerose volte il caso di test.

Un errore diffuso è la tendenza all’eccessiva automatizzazione, bisogna accuratamente selezionare i test che è conveniente automatizzare. Ad esempio è sconsigliabile automatizzare il testing di feature candidate a cambiare nell’immediato futuro o soggette a modifiche frequenti. Bisogna considerare che casi di test molto complessi potrebbero avere costi di automatizzazione troppo elevati rispetto all’esecuzione manuale degli stessi. In sintesi i casi in cui si rivela più conveniente automatizzare sono:

• la verifica della compatibilità dell’applicazione con una nuova versione del sistemaoperativo,
• la verifica che l’introduzione di nuove caratteristiche non abbia alterato la retrocompatibilità dichiarata sfruttando nuove API,
• i test di regressione,
• i test più frequenti e di lunga esecuzione,
• i test che hanno risultati predicibili,
• tutto quello che è facile da automatizzare in modo da ridurre i costi di realizzazione.

Dall’altra parte, eseguire manualmente i test ha come primo evidente svantaggio la lentezza, per poter accelerare e parallelizzare il testing su più dispositivi è necessario ingaggiare un numero maggiore di risorse umane con un conseguente aumento dei costi Il principale vantaggio è che per quanto accurati ed evoluti i framework non riescono a riprodurre in tutto e per tutto le interazioni di un un utente umano. Inoltre per avviare una sessione di test manuale non è necessaria alcuna infrastruttura se non il device reale o emulato ed il tester.

Per queste ragioni il testing manuale trova maggiore spazio nelle realtà aziendali minori o tra gli sviluppatori individuali dove spesso non esiste una divisione tra il team di sviluppo e quello di testing e non sono disponibili fondi per l’infrastruttura di automatizzazione.

Scripting

Nell’ambito della test automation si definisce scripting il processo di progettazione e stesura dei test. Questa fase consiste nel produrre un documento, un foglio di calcolo o un insieme di files sorgenti in cui tutti i casi di test sono raccolti assieme ai risultati attesi per ciascuno, in modo che per ogni esecuzione si possa determinare lo stato di fallimento o successo.

Più comunemente per test script si intende l’unità di software alla base della testing automation, realizzata in un linguaggio di programmazione.

Per fare in modo che gli script prodotti siano eseguibili ovunque e che possano adattarsi a tutti i dispositivi, indipendentemente dalle caratteristiche hardware e software, i linguaggi e le librerie utilizzati devono avere un elevato livello di astrazione. A tal scopo è possibile utilizzare framework e software di testing specializzati che forniscono linguaggi di alto livello per interagire con i widget del device in maniera indipendente dalla piattaforma.

Come analizzato nel paragrafo precedente, il principale svantaggio della produzione di script automatizzabili è il tempo necessario alla loro stesura.

Un buon compromesso tra eseguire i test a mano e sviluppare script automatici risulta essere registrare le interazioni di un utente reale con l’applicazione e convertirle in uno script rieseguibile. In questo modo anche uno scenario di test complesso può essere reso automatico in pochi minuti. I costi di questa tecnica sono molto bassi se si esclude l’acquisto di un tool specifico. Il test può essere eseguito da persone con esperienza minima purché il dispositivo sia collegato all’ambiente di sviluppo.

A causa delle differenze tra dispositivi e dei differenti livelli di astrazione dei linguaggi non è possibile ottenere una registrazione perfetta ma è possibile produrre script funzionanti intervenendo in percentuale minima sul codice prodotto.

Infine è possibile eliminare completamente la fase di stesura dei test affidandosi a dei tool in grado di ispezionare l’interfaccia dell’applicazione alla ricerca di widget e bottoni. Sebbene questi strumenti siano in grado di esplorare completamente le schermate di un’applicazione il loro utilizzo si rivela utile solo nelle prime fasi dello sviluppo in quanto non è possibile alimentarli con dati e prevedere combinazioni di input complesse.

Data Driven Testing

Si definisce Data Driven Testing una tecnica in cui tutti i parametri, le condizioni, gli input e gli output di un caso di test non sono cablati nel codice di scripting ma vengono prelevati ad ogni esecuzione da un sorgente dati specifica in modo da realizzare la separazione della parte logica. Molto spesso in applicazioni complesse, il numero di classi di equivalenza dei valori di input che è possibile inserire è troppo alto per poter essere coperto da test manuali o da altrettanti test script. In tali casi in genere si cerca di effettuare solo i test più significativi.

Il Data Driven Testing risolve questo limite garantendo i seguenti vantaggi:

• Può essere progettato per ogni singolo caso d’uso già durante la fase di sviluppo e riutilizzato in più casi di test.
• Aumenta la ripetibilità e la riusabilità dei test automatici riducendone la complessità: è possibile riutilizzare lo stesso script migliaia di volte con dati diversi anziché produrre uno script che replica migliaia di volte le stesse operazioni.
• Migliora la manutenibilità: in caso di aggiunta/modifica di campi di input e regole di validazione.
• Separa la logica del test dai dati rendendo gli script più lineari, leggibili e indipendenti dai dati.
• Produce casi di test più realistici: avere la possibilità di modificare spesso i dati di test, eventualmente producendoli di volta in volta in modo random, aumenta la probabilità di individuare nuovi bug.
• Riduce il numero di Test Case/Script: la separazione consente di rendere modulari e riutilizzabili sia I dati che gli script. Si evitano inutili duplicati e la gestione risulta snellita.