Teoria Locale

La automazione del test richiede: la implementazione dei casi di test in termini di “procedura per l’esecuzione automatica” (script) che lo rende un caso di test automaticamente eseguibile; la registrazione degli script che sono accumulati in un “patrimonio comune”; costruire un “oracolo” con la prima esecuzione caso di test che descrive la risposta attesa dall’esecuzione dello script; rieseguire i test selezionati dal patrimonio comune e verificare che il sistema testato risponda come registrato nell’oracolo.

I problemi essenziali nell’automazione del test sono:

• Quando sono rieseguiti gli script nel patrimonio comune il sistema testato potrebbe non risponde come prevede l’oracolo anche in assenza di failure (falsi positivi). I falsi positivi creano sprechi perché si spende tempo-persona, in quantità imprevedibile, per capire che si è in presenza di un falso positivo.
• Tester diversi che implementano lo stesso caso di test potrebbero impostare gli script in modo non equivalente così che eseguiti sullo stesso sistema nelle stesse condizioni non diano lo stesso risultato
• Il trasferimento dello stesso “patrimonio comune” tra tester diversi potrebbe avere problemi se gli script non sono comprensibili a tutti i tester che devono utilizzarlo.
• Quando si esegue un test di regressione non si riesce ad estrarre dal patrimonio comune tutti e solo gli script corrispondenti ai casi di test che servono per il test di regressione. Questo comporta o che si eseguano tutti gli script contenuti nel patrimonio comune o che il tester debba estrarli esaminando uno per uno tutti gli script. In entrambi i casi c’è spreco: nel primo perché aumenta la probabilità dei falsi positivi, c’è anche da considerare il tempo di esecuzione dei casi di test perché il patrimonio comune col tempo assume dimensioni sempre più grandi, nel secondo caso il tempo-persona da spendere è tanto più elevato quanto più grande è la dimensione del patrimonio comune.
• La dispendiosità della creazione degli script e del corrispondente oracolo che siano utilizzabili affidabilmente può essere dispendiosa.

Applicazione da testare. Sistema software insieme con eventuali dispositivi hardware che costituiscono il sistema da testare prima della consegna e della messa in esercizio produttivo.

Caratteristiche del tool. Capacità che caratterizzano il tool di automazione del test e che sono messe a disposizione del suo utilizzatore per produrre gli script e l’oracolo.

Caso di test. L’insieme dei dati in input al software e le condizioni di stato e di funzionamento dello stesso software insieme ai dati ed allo stato atteso dall’applicazione da testare. Esso costituisce una delle prove previste per verificare l’esatto comportamento del software.

Debugger. Sviluppatore che cerca e risolve i difetti disseminati in un’applicazione che causano un malfunzionamento evidenziato da un test.

Failure/Malfunzionamento. Incapacità di un sistema software o di un componente di eseguire le sue funzioni come è prescritto nelle specifiche dei requisiti descritti nel BRD. Durante lo sviluppo, i tester osservano solitamente i malfunzionamenti.

Falsi positivi. Risposte dell’applicazione testata sono rilevate come malfunzionamenti, ovvero non corrispondenti alla risposta che si aspetta l’oracolo, ma che sono solo dovuti a dettagli delle immagini o dei contenuti degli screen di risposta e che sono dovuti alle condizioni operative della infrastruttura ICT e non a dei fault esistenti nell’applicazione.

Fault/Difetto. Informazioni, dati, asserzioni o istruzioni incorrette in un documento o nel codice oppure un comportamento incorretto nella esecuzione di una attività, di un metodo o di una tecnica in un processo software. Un difetto viene introdotto nel software a seguito di un errore. È un’anomalia che può causare un comportamento del software prodotto non conforme alle sue specifiche.

Infrastruttura ICT. È l’insieme di tutti i dispositivi (rete di comunicazione, server, client, macchine diverse e così via) che costituiscono o simulano l’ambiente tecnologico in cui è in esercizio l’applicazione da testare.

Mappa di tracciabilità. Mappa che collega gli elementi della struttura dell’applicazione e delle relazioni tra gli elementi agli script nel patrimonio comune che sono serviti a testare il loro corretto comportamento.

Modifiche evolutive. Modifiche che cambiano l’applicazione facendola evolvere nelle funzioni e/o nei comportamenti e/o nelle caratteristiche tecniche.

Organizzazione del patrimonio comune. Classificazione degli script, secondo le possibilità che consente il tool, così che in ogni classe siano contenuti gli script che interessano al test di regressione di uno degli aspetti testabili dell’applicazione.

Patrimonio comune. Insieme degli script che corrispondono a tutti i casi di test utilizzati durante tutta la vita di un’applicazione per testare le sue caratteristiche inziali e quelle prodotte durante le manutenzioni evolutive della stessa. Il patrimonio comune contiene anche l’oracolo corrispondente agli script.

• Affidabile. Qualunque sia il sottoinsieme di script che vengono rieseguiti non si rilevano falsi positivi.
• Stabile. Qualunque script sia rieseguito più volte in condizioni differenti della infrastruttura ICT non faccia rilevare falsi positivi.
• Sistematico. Script differenti prodotti da tester diversi si comportano sempre in modo equivalente, ovvero danno gli stessi risultati come se fossero stati prodotti dallo stesso tester.
• Flessibile. Il patrimonio comune è configurabile automaticamente come contenente tutti e solo gli script che servono al test di regressione.

Piano di formazione strutturato. Insieme di unità didattiche con le relazioni di sequenza che costituiscono il percorso di formazione di un tester.

Piani di test. L’insieme dei casi di test a cui sarà sottoposto il software di cui si vuole provare la completezza e la correttezza.

Pratiche di programmazione. Sono pratiche utilizzabili nella produzione dello script in modo che il tool rilevi i risultati del sistema testato con una tempistica che consenta di trascurare eventuali rumori creati dalla infrastruttura ICT e l’oracolo riconosca la risposta esatta da parte del sistema trascurando i dettagli di immagine e di contenuti degli screen di risposta allo script.

Principi di strutturazione del patrimonio comune. Principi che guidano come strutturare il patrimonio comune in modo da ottimizzare la sua organizzazione rispetto alla selezione degli script che servono in ciascun piano di test di regressione.

Rilievo. Una difformità del codice rispetto allo standard d’uso del linguaggio.

Script. Procedura scritta nel linguaggio previsto dal tool che implementa le azioni che devono essere eseguite per implementare un caso di studio e le verifiche che devono essere fatte sull’output dell’applicazione da testare per decidere se questo è corretto secondo quanto previsto dal piano di test.

Software impattato. Le parti della struttura dell’applicazione che sono impattati dalla modifica realizzata.

Spreco. Tutto ciò che è speso nello sviluppo o manutenzione del software che non porta valore a nessuna delle parti interessate.

Struttura delle applicazioni. Elementi che compongono le applicazioni e relazioni tra loro. Utili per prevedere qual è l’impatto di propagazione di una modifica nell’intera applicazione. Gli elementi e le relazioni impattate devono essere testate nuovamente dopo la modifica per verificare la eventuale regressione.

Test di Regressione. L’insieme degli script da eseguire corrispondenti al piano di test di regressione che a sua volta serve a rilevare se con le modifiche evolutive realizzate si è generata qualche regressione.

Tester. Sviluppatore che i seguenti compiti: produrre gli script che implementano i casi di test, organizzarli nel patrimonio comune, selezionare gli script che devono comporre il piano di test di regressione e farli eseguire dal tool.

Tool. Sistema software che consente la produzione degli script, li raccoglie; produce l’oracolo in corrispondenza ad ogni script con la prima esecuzione dello stesso, consente la organizzazione degli script in modo che sia facilitata la selezione della parte di patrimonio comune che serve per uno specifico test di regressione. Qualche volta questo tool deve anche simulare le macchine che originano i dati di input che servono allo script per essere eseguito.

• Il tester utilizza un insieme di pratiche di programmazione, dipendenti dal tool e dall’infrastruttura ICT in cui operano le applicazioni da testare, descritte rigorosamente per produrre gli script che implementano il caso di test che devono essere rieseguiti e che costituiscono il patrimonio comune: affidabile, stabile e sistematico con cui si produce il test di regressione; così che siano rilevati, in definitiva, il minimo di falsi positivi.
• Il tester deve progettare l’organizzazione del patrimonio comune secondo principi di strutturazione del patrimonio comune rigorosamente descritte, dipendenti dalle caratteristiche del tool e dalla struttura delle applicazioni da testare, per costituire una mappa di tracciabilità che consenta di selezionare, il più automaticamente possibile, gli script che testano il software impattato dalle modifiche evolutive delle applicazioni, così da avere patrimonio comune flessibile rispetto al test di regressione.
• Per un tester deve essere previsto un piano di formazione strutturato circa le pratiche di programmazione degli script, dell’organizzazione del patrimonio comune, delle caratteristiche del tool, della struttura delle applicazioni e principi di strutturazione del patrimonio comune per poter produrre gli script organizzarli nel patrimonio comune e riusare efficacemente quest’ultimo.

• Gli script guidano il tool sulla produzione dell’oracolo quando esso è eseguito la prima volta e come deve interpretare la risposta del sistema sottoposto al caso di test corrispondente allo script per decidere che quest’ultima sia uguale a quella depositata nell’oracolo. Infatti lo script fa sì che l’oracolo non consideri nella risposta i dettagli nell’immagine e nei contenuti dello screen che possono essere trascurabili nella valutazione della risposta e che possono dipendere da condizioni contingenti dell’applicazione o della infrastruttura su cui quest’ultima è in esercizio che si verificano quando è eseguito (per esempio carico della linea, ritardi nella risposta del sistema software, ecc.). Questo fa sì che il tool non evidenzi failure che non dipendono dal comportamento dell’applicazione e che quindi sono falsi positivi, così che l’oracolo risulti affidabile e stabile. Essendo le pratiche descritte rigorosamente, tester diversi producono per lo stesso caso di test script che hanno gli stessi risultati nella valutazione delle risposte alla riesecuzione dello stesso caso di test, quindi la produzione del patrimonio comune risulta sistematica.
• Una mappa che metta in relazione ogni caratteristica testabile dell’applicazione e i casi di test che la testano dà la possibilità ai tester di selezionare rapidamente e con l’impiego di poco tempo-persona i casi di test che devono essere impiegati nel test di regressione per testare solo le parti del software che sono state impattate dalla modifica realizzata. La rapidità e il tempo-persona necessario dipendono dalle capacità di selezione dal patrimonio comune che mette a disposizione il tool.
• Il tester con le competenze adeguate circa le pratiche di produzione degli script, le caratteristiche del tool che li deve eseguire e le caratteristiche dell’ambiente in cui sono eseguite le applicazioni riesce a produrre script affidabili e stabili. Altresì, deve avere competenze di progettazione della mappa di tracciabilità per rendere flessibile il patrimonio dicasi di test rispetto ad ogni test di regressione, ovvero rendere selezionabili con poco tempo-persona tutti e solo i casi di test che servono per ogni test di regressione da eseguire.

1. L’acquisizione di uno strumento per l’esecuzione automatica del test di regressione potrebbe essere molto dispendiosa se risultano complesse le pratiche per produrre gli script in modo affidabile, stabile e sistematico per le capacità di apprendimento del tool e per quelle che mette a disposizione nel linguaggio di programmazione degli script soprattutto per lo screen-matching attraverso il quale l’oracolo deve valutare l’esattezza della risposta del sistema testato. Per mitigare questo rischio è necessario sperimentare il tool prima che lo si adotti. Non basta, in questo caso, una Proof Of Concept, perché non si conoscono a priori le funzioni ed i comportamenti che ci si aspetta dal tool. Infatti, ogni tool può implementare le capacità che cerchiamo in modo diverso, quindi sono da testare i tool candidati per verificare come siano efficaci le funzioni che mette a disposizione per implementare le capacità di cui abbiamo bisogno.
2. Le pratiche di programmazione degli script e di progettazione del patrimonio comune potrebbero risultare carenti per insufficiente esperienza o perché si modificano le capacità del tool, le caratteristiche delle applicazioni da testare. Per mitigare questo rischio è opportuno monitorare l’efficacia dell’uso del tool nel test di regressione ed intervenire con le iniziative di miglioramento quando questa efficacia è considerata insufficiente o degrada rispetto alle soglie desiderate dall’impresa.
3. La formazione di un tester non adeguata può sprecare il lavoro dello stesso tester e dei debugger che devono analizzare le cause delle failure evidenziate dal tool quando queste sono dei falsi-positivi. Questo rischio si mitiga attraverso la progettazione e la implementazione di un corso che abbia tutte le componenti per costituire le competenze necessarie al test da erogare ai neofiti. Deve, inoltre, essere creato un modello di qualità per monitorare continuamente l’efficacia delle competenze dei tester e se questa è carente sarà necessario il miglioramento del corso. Altresì, ogni miglioramento del corso deve attivare l’aggiornamento dei tester già operativi.

1. Con l’uso di un tool per l’automazione del test si migliora:
   • Le partiche di programmazione degli script;
   • Le pratiche di organizzazione del patrimonio comune;
   • I corsi di formazione dei tester.

   Pertanto queste componenti sono dei veicoli di accumulazione di conoscenza.

   Tale conoscenza sarà diversificato per tipo di tool utilizzato e per struttura delle applicazioni. Per esempio in Auriga ci sono due tool:

   • FIS per le applicazioni che funzionano su ATM e CSA;
   • TEST COMPLETE per le applicazioni WEB.