From 0 to hero

La sfida di un team dedicato al testing non è solo quella di intercettare e bloccare il maggior numero di bug, ma quella di dare supporto sia al business aiutandolo a stilare una documentazione dettagliata, sia al team di sviluppo dettagliando le anomalie riscontrate.
Un tester oltre ad essere uno sviluppatore, è un esperto nel collaudo di un software.
Il suo compito principale è preparare ed eseguire i test necessari per verificare la funzionalità del software.
Trovare un bug prima di portare il codice in produzione, permette di abbattere i costi di sviluppo, evitando inutili rework post rilascio. Avere un solido processo di Quality Assurance (QA), consente di avere un prodotto più solido e di qualità superiore.

Cos’è il Testing Automation e a cosa serve?

Il Testing Automation (cardine fondamentale di un processo di QA) è la soluzione migliore per garantire un prodotto privo di BUG, mantenendo questa sicurezza ad ogni nuova versione rilasciata ed avendo la certezza che i requisiti funzionali siano stati rispettati fin dagli albori del progetto.
Avere dei test automatici rispetto ai classici test manuali, riduce notevolmente i tempi di sviluppo e di testing. Questi vengono eseguiti principalmente nelle ore di inattività dello sviluppo, permettendo l’esecuzione parallela su più browser e device, sia da mobile sia da desktop.
Un processo di Testing Automation permette di testare in maniera dettagliata e minuziosa quelli che sono le due categorie principali di test:

• End To End (E2E) di integrazione, che controllano il modo in cui i flussi di dati attraversano i sistemi integrati;
• Scenari End To End funzionali, che verificano le funzionalità del prodotto così come è percepito dall’utente finale.

Tutti gli sviluppatori sanno che su progetti ad elevata e media complessità, ogni nuova funzionalità rilasciata può provocare sia bug legati alla funzionalità sia regression sul codice già consolidato. Implementare un processo di Quality Assurance corredato da test automatici, da la possibilità di eseguirli con un minimo effort temporale ogni qualvolta che se ne ha la necessità; ad esempio, accoppiando i test con i flussi di Continuous Integration e di Continuous Delivery. Inoltre, si evitano l’errore umano, i lunghi e ripetitivi test svolti a mano che possono portare il tester a commettere errori di distrazione, oltre alla perdita di dettagli utili riguardanti il malfunzionamento.

Come implementare un processo di Testing

Un processo di Testing Automation è suddiviso generalmente in 7 fasi ben distinte anticipate da uno stadio preliminare fondamentale in cui far capire a chi gestisce e sviluppa il progetto l’utilità di avere una gestione automatica dei test E2E (sia d’integrazione, sia funzionali).
Le 7 fasi del processo di testing sono le seguenti:

1. Suddivisione delle aree funzionali di testing e creazione delle Test Suite Funzionali (TSF), ossia le macro-aree del progetto da testare. Ad esempio, per un e-commerce potremmo dividere le TSF in profilo utente, checkout, carrello, processo di resi, etc.
2. Suddivisione delle funzionalità (FT) legate ad ogni TSF (chiaramente ogni area funzionale ha delle criticità che vengono testate separatamente). Ad esempio, la TSF profilo utente comprende le FT login, il logout, l’inserimento dei dati, la modifica dei dati, etc.
3. Scelta dei test o scenari da automatizzare per ogni funzionalità (SC) con il linguaggio Cucumber (Gherkin). Ad esempio, per la FT profilo utente verrà creato lo scenario login con dati corretti, il login con password sbagliata, il login con username sbagliata etc.
4. Dopo aver strutturato i test, si passa all’automazione dei test tramite Behat.
5. Si vanno a strutturare i test plan, ossia le TSF da lanciare in base alle varie esigenze di business
6. Esecuzione dei test cross device e cross browser sfruttando Browserstack Automate
7. Analisi dei risultati dei test

Le prime tre fasi sono finalizzate alla scrittura dei test e alla suddivisione delle aree funzionali da testare.
Di seguito, un esempio di uno scenario di test:

Come si può notare dall’immagine precedente, lo scenario è suddiviso in step Given, When e Then, che fungono da parole chiavi. Given rappresenta lo stato di partenza dell’applicazione, When rappresenta l’azione da testare e Then rappresenta il risultato atteso.
L’insieme delle Test Suite Funzionali rappresenta un’estensione della documentazione di progetto, che di fatto ne valida tutti gli “use case” ed è utile sia al business sia agli sviluppatori. Il fornitore sa che deve implementare tutte le funzionalità censite negli scenari, così come sono descritti.
Il processo di testing prosegue con la trasformazione dei vari step visti nell’immagine precedente in codice funzionale e serve a creare l’automazione.
Di seguito un esempio:

Esecuzione dei Test

L’esecuzione vera e propria dei test avviene su Browserstack, uno strumento che mediante api (Application Program Interface) permette di eseguire test su più dispositivi (Desktop e Mobile) e su più browser differenti.
Browserstack non fornisce dei semplici ambienti virtuali, ma macchine fisiche.
L’output di tale strumento è composto da:

• Un video per ogni test eseguito
• Un report in formato JSON, con tutte le informazioni d’esecuzione per ogni test eseguito

L’esecuzione dei test su Browserstack da remoto è resa possibile dalla combinazione di due strumenti: Behat e Selenium.

Il primo si occupa di collegare lo scenario scritto in Gherkin al codice automatico corrispondente; il secondo è un insieme di API e funzioni che permettono di “pilotare” un browser da remoto. Quest’ultimo rende possibile l’esecuzione dello scenario di test, convertito in codice da Behat. Di seguito un'immagine che descrive il processo d’integrazione tra Behat, Selenium e Browserstack.

Gestione dei Bug ed elaborazione dei Test Plan

Una volta scritti, automatizzati e lanciati i test, il processo è finito e non resta che segnalare al team di sviluppo i bug rilevati.
Utilizzando Browserstack c’è la possibilità di aprire i bug (tramite interfaccia o API) direttamente su un issue tracker. Tra quelli supportati vi sono Jira, Trello e GitHub. In alternativa si può anche schedulare una notifica su Slack.
Un valore aggiunto in un processo di Testing Automation è sicuramente quello di creare più Test Plan (combinazione di più TSF) in base alle esigenze e alle fasi di progetto.
Un approccio vincente è quello di scegliere i processi End To End principali e gli Happy Path, ossia i processi indispensabili che devono essere funzionanti prima di andare on-line. 
Sia gli End to End, sia gli Happy Path vengono eseguiti con maggiore frequenza, mentre l’intero set di test è lanciato a cadenza maggiore.
Per permettere la gestione dei Test Plan (scegliendone i dispositivi e i browser), il monitoraggio dei risultati e l’apertura dei bug, Hinto mette a disposizione una piattaforma e un team dedicato.
La piattaforma sviluppata da noi interamente (mixando tecnologie nuove e consolidate come GO, PHP e React) permette il controllo e la gestione di tutti i flussi di test.
Inoltre, viene offerto un team dedicato per seguire tutta la fase di testing, dall’analisi dei requisiti alla scrittura ed automazione dei test fino all’analisi e notifica dei Bug.