Il Test Lab alla prova: l’esperienza personale del Tester

Introduzione

 Il Test del Software è un’attività complessa, imprescindibile dall’applicazione di una metodologia accurata e dalla proprietà di un set di conoscenze tecniche ed esperienze operative, da parte del Tester, per apportare un vantaggio competitivo a chi necessita del servizio.

#DaleTestLab è un “asset”strategico  aziendale configurandosi come punto di riferimento per il Testing in grado di consentire il corretto funzionamento di determinate applicazioni.

Raccontare  l’attività del Lab, attraverso la testimonianza di un Tester e la sua esperienza in un contesto Cliente, significa raccordare il piano tecnico e funzionale dell’attività di Testing ed evidenziare l’elemento di unicità che contraddistingue il nostro Team.

La testimonianza condivisa in questo articolo evidenzia le sfide nell’attività di Testing e l’importanza strategica del ruolo del Tester, chiamato a verificare le User-Experience validando il  funzionamento di una soluzione digitale.

Il racconto di Ivan

La posizione di Ivan acquisisce un ruolo strategico nel momento in cui nasce l’esigenza del cliente di avere un contributo specifico per la fase di testing manuale. Il progetto nasce all’interno del settore bancario per un’impresa che si occupa di Product Governance; l’obiettivo dell’azienda è rilasciare una piattaforma  funzionante che soddisfi tutti i requisiti e consenta al delivery manager di avere una soluzione pronta ed utilizzabile per un cliente specifico. L’attività di Ivan e degli altri colleghi consiste nel certificare parte di tale applicativo digitale e confermare l’attività del software prima del rilascio; il processo di qualità del prodotto avviene in un contesto AGILE, seguendo la metodologia SCRUM dove varie fasi sono separate in “Sprint”( schema temporale per le fasi di progetto) per consentire una gestione ottimale nel validare gli scenari di funzionamento. Per la mansione concreta del test del software, il Team esegue una serie di attività  metodologicamente accurate per aiutare a certificare il prodotto,come: analisi dei requisiti, pianificazione dei test,sviluppo dei casi di  prova, configurazione dell’ambiente, esecuzione del test, chiusura del ciclo di prova. Nello specifico, Ivan si occupa di:

“Principalmente, il mio compito è effettuare test manuali senza utilizzare strumenti o script automatizzati, assumendo il ruolo di utente finale e testando il software per identificare eventuali comportamenti o bug imprevisti. Queste attività vengono eseguite con l’uso di piani di test, testbook con relativi casi di test o scenari di test per garantirne la completezza.”

“Dal punto di vista operativo, la mia attività si esplica in 2 fasi: preparatoria ed esecutiva. La prima fase consiste nell’analizzare documenti di Business Analysis e dati in grado di descrivere il software e vari processi; tale attività è funzionale nel preparare casi di test specifici e concettualizzare scenari da validare. Nel frattempo gli sviluppatori rilasciano nuove funzionalità da testare, arrivando ad una fase esecutiva: il mio compito è configurare ambienti preposti all’esecuzione dei test ed assicurare che l’applicativo funzioni in modo corretto, ovvero individuare bug, se presenti, ed indirizzarli allo sviluppatore per l’attività di fixing. Alla fine , consegno un report a corollario con il pacchetto di rilascio dove descrivo l’attività metodica eseguita nel ciclo di test che evidenzia la certificazione del software”.

Codice Gherkin

Il linguaggio Gherkin è correlato all’approccio BDD(Behavior-Driven-Development), tale codice è utilizzato per descrivere casi d’uso preparatori per un sistema software in modo che possa essere letto e compreso facilmente.

Il progetto in questione richiede di preparare casi di test scritti per un linguaggio propedeutico per l’automazione, in questo caso il codice Gherking diventa uno strumento fondamentale per assolvere tale compito. Ogni scenario BDD segue il medesimo pattern: dato un contesto(Given), un evento(When) produce un risultato(Then).

“Per scrivere i test Gherkin, è stato utilizzato il modello descrittivo basato su i seguenti elementi della sintassi:

• Feature: una descrizione di ciò che il software dovrebbe fare. Questa parola chiave viene utilizzata anche per raggruppare gli scenari.

•Rule : norma aziendale che deve essere inclusa. Ciò fornisce il contesto per una funzionalità.

• Given: fornisce il contesto del sistema prima che un utente inizi a interagire con esso.

• When: riferimento ai  passaggi di azione. Descrivono un evento.

• Then: passaggi di risultato.

• And, But – Quando si dispone di più di uno dei tipi di passaggio sopra elencati, è possibile utilizzare “e” o “ma”.

• Background: consente di aggiungere ancora più contesto agli scenari in una funzionalità.

• Outline: scenario che contiene una sezione di esempi.

L’obiettivo è evidenziare i requisiti del progetto dell’azienda. Ciò garantisce un processo di sviluppo costruito pensando all’esperienza dell’utente.”

Il Testing è un valore fondante del Team di Dale Consulting; l’esperienza di Ivan sintetizza il mix di professionalità e competenze richieste dai Tester per il miglioramento delle applicazioni dei clienti ottimizzando al meglio le tecnologie con un accurato test del software e validazione della User Experience.