Automatizzare casi di test: Approccio scripting lineare, strutturato, data-driven e keyword-driven

I casi di test devono essere tradotti in sequenze di azioni che sono eseguite sul SUT (System Under Test). Tali sequenze di azioni possono essere documentate in una procedura di test e possono essere implementate in script di test. Oltre alle azioni, i casi di test automatizzati devono anche definire i dati di test per l’interazione con il SUT e includono i passi di verifica per verificare che il risultato atteso sia stato ottenuto dal SUT.

Approcci consolidati per automatizzare i casi di test comprendono:

Approccio cattura/riesecuzione;
Approccio con scripting lineare e strutturato, approccio data-driven e approccio keyword-driven;
Approccio process-driven e testing model-based.

Scripting lineare

Come tutte le tecniche di scripting, lo scripting lineare parte da alcune procedure di test manuali. Da notare però che queste possono non essere documenti scritti infatti la conoscenza su quali test eseguire e come eseguirli può essere posseduta da uno o più Analisti del Test.
Ogni test viene eseguito manualmente mentre lo strumento di test registra la sequenza delle azioni e in alcuni casi cattura gli output visibili del SUT su schermo. Questo generalmente produce come risultato uno script, di solito molto grande, per ciascuna procedura di test. Gli script registrati possono essere in seguito modificati per migliorare la leggibilità, per esempio aggiungendo commenti in punti chiave per spiegare cosa sta succedendo, o per aggiungere ulteriori controlli usando il linguaggio di scripting dello strumento.
Gli script possono quindi essere rieseguiti dallo strumento, facendo ripetere allo strumento le stesse azioni eseguite dal tester quando lo script è stato registrato. Sebbene questa modalità possa essere usata per automatizzare test dalla GUI, non è una buona tecnica da utilizzare quando deve essere automatizzato un grande numero di test e tali test devono essere usati per molte release del software. Questo a causa dell’alto costo di manutenzione tipicamente causato dalle modifiche al SUT (ogni modifica al SUT può rendere necessari molti cambiamenti agli script registrati).

I vantaggi dello scripting lineare si concentrano sul fatto che è richiesto un lavoro di preparazione minimo o del tutto nullo prima che si possa iniziare ad automatizzare. Una volta che si è imparato ad usare lo strumento di automazione è solo una questione di registrare un test manuale e rieseguirlo sebbene la parte di registrazione può richiedere un’interazione aggiuntiva con lo strumento di automazione per realizzare la comparazione tra i risultati reali e quelli attesi per verificare che il software stia funzionando correttamente. Infiene, non sono richieste capacità di programmazione anche se sono di solito utili per questo tipo di approccio.

Gli svantaggi degli script lineari sono numerosi. L’ammontare di lavoro richiesto per automatizzare ogni data procedura di test sarà per lo più dipendente dalla dimensione (numero di passi o azioni) richiesta per eseguirla. Così, la millesima procedura di test da automatizzare richiederà una quantità di lavoro simile in proporzione alla centesima procedura di test. In altre parole, non c’è molto spazio per diminuire il costo di realizzazione di nuovi test automatizzati.
Inoltre, se ci fosse un secondo script che eseguisse un test simile, sebbene con differenti valori di input, lo script conterrebbe la stessa sequenza di istruzioni del primo script; solo le informazioni contenute nelle istruzioni (argomenti o parametri delle istruzioni) sarebbero diverse. Se ci fossero vari test (e quindi script) essi conterrebbero tutti la stessa sequenza di istruzioni, ognuna delle quali dovrebbe essere manutenuta quando il software cambiasse in modo tale da influenzare gli script.
Poiché gli script sono realizzati in un linguaggio di programmazione, piuttosto che in linguaggio naturale, chi non è programmatore può trovare difficoltà nel comprenderli. Alcuni strumenti di test usano linguaggi proprietari (unici per lo strumento) che richiedono del tempo per essere appresi e diventare produttivi.
Gli script registrati contengono solo frasi generiche nei commenti, se presenti. Script lunghi in particolare sono meglio documentati, con commenti che spiegano cosa si sta facendo ad ogni passo del test. Ciò rende la manutenzione più facile. Gli script possono diventare presto molto grandi (contenendo molte istruzioni) quando il test comprende molti passi.
Infine, gli script non sono modulari e difficili da manutenere e in particolare, lo scripting lineare non segue i comuni paradigmi di riusabilità e modularità del software ed è strettamente legato allo strumento che si sta usando.

Scripting strutturato

La maggiore differenza tra la tecnica di scripting strutturato e la tecnica di scripting lineare è l’introduzione di una libreria di script. Questa contiene script riusabili che eseguono sequenze di istruzioni comunemente richieste da un certo numero di test. Buoni esempi di tali script sono quelli che si interfacciano, per esempio, con le operazioni delle interfacce del SUT.

I benefici di tale approccio includono una riduzione significativa nelle modifiche richieste in manutenzione e un costo ridotto nell’automatizzare nuovi test (perché si possono usare script che già esistono piuttosto che doverli creare tutti da zero).
I vantaggi dello scripting strutturato sono largamente realizzati per mezzo del riuso degli script. Più test possono essere automatizzati senza dover creare il volume di script che un approccio di scripting lineare richiederebbe. Questo ha un impatto diretto sui costi di realizzazione e manutenzione. Il secondo test e i seguenti non richiederanno lo stesso sforzo per l’automazione perché potranno essere riusati di nuovo alcuni degli script creati per implementare il primo test.

I benefici di tale approccio includono una riduzione significativa nelle modifiche richieste in manutenzione e un costo ridotto nell’automatizzare nuovi test perché si possono usare script che già esistono piuttosto che doverli creare tutti da zero.
I vantaggi dello scripting strutturato sono largamente realizzati per mezzo del riuso degli script. Più test possono essere automatizzati senza dover creare il volume di script che un approccio di scripting lineare richiederebbe. Questo ha un impatto diretto sui costi di realizzazione e manutenzione. Il secondo test e i seguenti non richiederanno lo stesso sforzo per l’automazione perché potranno essere riusati di nuovo alcuni degli script creati per implementare il primo test.

Lo sforzo iniziale per creare gli script condivisi può essere visto come uno svantaggio di questo approccio, ma questo investimento iniziale si ripagherà abbondantemente se approcciato in modo appropriato. Saranno richieste capacità di programmazione per creare tutti gli script, perché solo una semplice registrazione non sarà sufficiente. La libreria di script deve essere ben gestita, cioè gli script devono essere documentati e deve essere facile per l’Analista Tecnico del Test trovare gli script richiesti.

Testing Data-driven

La tecnica di scripting data-driven è basata sulla tecnica di scripting strutturato. La differenza più significativa è come sono gestiti i dati di input. Gli input sono estratti dagli script e messi in uno o più file separati chiamati tipicamente file di dati (data file).
Ciò significa che lo script di test principale può essere riusato per implementare un certo numero di test piuttosto che solo un singolo test. Tipicamente lo script principale riusabile è chiamato lo script di controllo. Lo script di controllo contiene la sequenza di istruzioni necessarie per eseguire i test, ma legge i dati di input da un file di dati. Un solo test di controllo può essere usato per molti test, ma è di solito insufficiente per automatizzare un ampio insieme di test. Quindi, sarà richiesto un certo numero di script di controllo, ma questo sarà solo una frazione del numero di test che sono automatizzati.

Il costo di aggiungere nuovi test automatizzati può essere ridotto significativamente da questa tecnica di scripting. Questa tecnica è usata per automatizzare molte variazioni di un test, fornendo un testing più approfondito in un’area specifica e quindi potendo aumentare la copertura del testing.
Avere dei test descritti da file di dati comporta che l’Analista del Test (Test Analyst) può specificare test automatizzati semplicemente popolando uno o più file di dati. Ciò dà all’Analista del Test più libertà di specificare test automatizzati senza troppa dipendenza dall’Analista Tecnico del Test (technical test analyst) che generalmente non è una risorsa presente nelle aziende.

Il bisogno di gestire i file di dati e assicurarsi che siano leggibili dalla TAS è uno svantaggio, ma può essere affrontato in modo appropriato.
Inoltre, possono essere persi alcuni importanti casi di test negativi. I test negativi sono una combinazione di procedure di test e dati di test. In un approccio che punta principalmente ai dati di test, è possibile che “le procedure di test negative” siano trascurate.

Testing Keyword-driven

La tecnica di scripting keyword-driven si basa sulla tecnica di scripting data-driven. Ci sono due principali differenze:

i file di dati sono ora chiamati file di definizione del test o qualcosa di simile (per esempio file delle action word);
c’è un solo script di controllo.

Un file di definizione del test contiene una descrizione dei test che sia facile da comprendere da parte dell’Analista del Test (più facile di un equivalente file di dati). Di solito conterrà dati come i file di dati, ma i file di keyword conterranno anche istruzioni ad alto livello (le keyword, o action word).
Le keyword devono essere scelte in modo che abbiano significato per l’Analista del Test, per i test descritti e per l’applicazione testata. Esse sono principalmente (ma non esclusivamente) usate per rappresentare interazioni di business di alto livello con un sistema (per esempio “crea un ordine”). Ogni keyword rappresenta un certo numero di interazioni dettagliate con il sistema sotto test. Sequenze di keyword (compresi i dati di test necessari) sono usate per specificare i casi di test. Keyword speciali possono essere usate per i passi di verifica o le keyword possono contenere sia le azioni che i passi di verifica.
L’ambito di responsabilità dell’Analista del Test include la creazione e la manutenzione dei file di keyword. Ciò significa che una volta che gli script che le implementano sono realizzati, l’Analista del Test può aggiungere test ‘automatizzati’ semplicemente specificandoli in un file di keyword (come con lo scripting data-driven).

Una volta che lo script di controllo e gli script che realizzano le keyword sono stati scritti, il costo di aggiungere nuovi test automatizzati sarà molto ridotto da questa tecnica di scripting.
Anche in questo approccio, avere i test descritti da file di keyword significa che l’Analista del Test può specificare test automatizzati semplicemente descrivendo i test tramite le keyword e i dati associati. Ciò rende l’Analista del Test più libero di specificare test automatizzati senza dipendere troppo dall’Analista Tecnico del Test. Il beneficio a questo riguardo dell’approccio keyword-driven rispetto all’approccio data-driven è dato dall’uso delle keyword. Ciascuna keyword deve rappresentare una sequenza dettagliata di azioni che produce qualche risultato significativo. Per esempio, ‘creare un’utenza’, ‘inserire un ordine’, ‘controllare lo stato dell’ordine’ sono tutte azioni possibili per un’applicazione di shopping online che comprendono un certo numero di passi dettagliati. Quando un Analista del Test descrive un test di sistema ad un altro Analista del Test, è probabile che essi parlino tra loro in termini di queste azioni ad alto livello, non dei passi dettagliati. L’obiettivo dell’approccio keyword-driven quindi è di implementare queste azioni ad alto livello e consentire che i test siano definiti in termini di azioni ad alto livello senza riferimento a passi dettagliati.
Questi casi di test sono più facili da manutenere, leggere e scrivere poiché la complessità può essere nascosta nelle keyword (o nelle librerie, nel caso di un approccio di scripting strutturato).

Infine, le keyword possono offrire un’astrazione dalle complessità delle interfacce del SUT. Inoltre, implementare le keyword rimane un impegno significativo per i test automation engineer, in particolare se si usa uno strumento che non offre alcun supporto per questa tecnica di scripting. Per piccoli sistemi può esserci troppo overhead per implementarle e i costi possono superare i benefici.
È necessario prendere precauzioni per assicurarsi che siano implementate le keyword corrette. Delle buone keyword saranno usate spesso in molti test differenti, mentre keyword di scarsa qualità è probabile che siano usate solo per una o poche volte.