Preparazione degli script di test

5.2.1 Il test

Il test è una parte essenziale del ciclo di sviluppo del software. È considerata un’importante attività in cui il software viene convalidato in conformità ai requisiti e alle specifiche. Si stima che per le attività di test viene speso dal 20% all’80% del costo totale del progetto di sviluppo di un software. Normalmente, per garantire il funzionamento di qualsiasi pezzo di codice scritto, deve esserci una fase di test per scoprire se il codice reagisce come previsto. Lo scopo principale del test del software è rilevare i difetti. Secondo lo IEEE Standard 610.12-1990 (“IEEE standard glossary of software engineering terminology”), il test del software è definito come “il processo di analisi di un elemento del software al fine di rilevare le differenze tra le condizioni esistenti e le condizioni richieste, chiamate bug, e di valutare le funzionalità degli elementi del software”. Nonostante la definizione, il test non può essere un processo separato dal ciclo di sviluppo del software. Dunque, l’elemento sottoposto a test potrebbe non funzionare come previsto e per questo deve essere testato e convalidato. La valutazione dovrebbe avvenire durante l’intero ciclo di sviluppo del software. In genere, si accetta il fatto che un software perfetto sia impossibile da ottenere. Pertanto, è richiesto il test e la valutazione continua dello stesso. L’obiettivo principale del test è fornire informazioni sulla qualità degli elementi sottoposti a test. Lo sviluppo di software di grandi dimensioni implica molte attività che necessitano di essere adeguatamente coordinate per soddisfare i requisiti desiderati. Tra queste, è possibile distinguere le attività che contribuiscono principalmente allo sviluppo del software, dalle attività che mirano a verificare la qualità dello sviluppo del processo e degli artefatti rilasciati. Questa classificazione non è nitida, dal momento che la maggior parte delle attività contribuisce in egual misura sia allo sviluppo del prodotto, sia al test dello stesso e quindi al controllo della qualità. In alcuni casi, questa caratterizzazione delle attività non è abbastanza precisa, ma aiuta a identificare un thread importante del processo di sviluppo che include tutte quelle attività di controllo della qualità e che viene definito semplicemente come “processo di qualità”. Il processo di qualità non è una fase, ma attraversa l’intero ciclo di sviluppo: inizia con

112

lo studio di fattibilità e continua dopo il rilascio del prodotto finale, dapprima in quello che costituisce il supporto post go-live, e successivamente durante il periodo di mantenimento del sistema. Le qualità rilevanti per il prodotto devono essere definite nello studio di fattibilità. Requisiti e specifiche di progettazione devono essere verificati e analizzati il prima possibile per identificare e rimuovere errori di progettazione altrimenti difficili da rilevare e estremamente costosi da eliminare. I test devono essere progettati e pianificati nelle primissime fasi di progettazione in modo tale da migliorare le specifiche e ridurre le probabilità di rilascio di funzionalità mal testate e prodotti di bassa qualità, e devono essere eseguiti molte volte attraverso i diversi sviluppi e corrispondenti rilasci per evitare la regressione delle funzionalità del prodotto, ovvero delle anomalie di funzionalità esistenti che si verificano dopo aver apportato una modifica al codice. Il processo di qualità include molte attività complementari che devono essere opportunamente combinate per adattarsi allo specifico processo di sviluppo e soddisfare i requisiti di costo e di qualità. Il responsabile della qualità talvolta deve affrontare requisiti contradditori, come mantenere bassi i costi e alta la qualità, oppure evitare interferenze con il processo di sviluppo e rispettare scadenze stringenti. La selezione di un insieme adeguato di attività di controllo della qualità è difficile e richiede una profonda esperienza di validazione del software, una forte conoscenza della progettazione e dello sviluppo, un buon background di gestione e pianificazione, ed eccellenti capacità di mediazione di diversi aspetti e necessità. Le attività di controllo riguardano due differenti classi di problemi: l’identificazione dei difetti e la valutazione della maturità del prodotto. La qualità non può essere aggiunta alla fine del processo, ma deve essere coltivata durante l’intero ciclo di sviluppo. Importanti categorie di failure sono di difficile rilevazione e rimozione una volta che il prodotto ha raggiunto la sua versione finale. Molte tecniche di analisi e di test mirano alla rilevazione dei difetti e alla loro rimozione attraverso il processo di sviluppo del sistema, cosa che contribuisce ad aumentare la qualità del prodotto finale ma che non può assicurare l’assenza di difetti dopo il rilascio della soluzione finale. Tuttavia, protrarre questo processo di rilevazione e conseguente rimozione dei difetti nel tempo porterebbe a eseguire per sempre attività di controllo qualità senza alcun fondamento logico. Gli utenti, infatti, sono interessati a un software in termini di affidabilità, usabilità, economicità e conformità ai requisiti, e non in termini di numero di difetti evitati o rimossi. Risulta importante, quindi, bilanciare

113

attività di identificazione e risoluzione di difetti con attività tese a stimare la maturità di un prodotto in termini di affidabilità e usabilità, trovando il giusto compromesso.

5.2.2 Metodologia di test ibrido-agile

Le categorie di test che vengono eseguite nello Sprint Delivery cycle nelle fasi di Design/Build/Validate e successivamente di Test & Deploy sono:

• Unit Test (UT): consiste nel testare i componenti custom, le interfacce e, eventualmente, alcuni componenti di configurazione complessi;

• Scrum Feature Testing (SFT): verifica che le funzionalità e le user story sviluppate e testate dallo scrum team soddisfino i risultati aziendali previsti;

• Cross Scrum Testing (CST): si tratta di tutti quei test di integrazione del sistema che richiedono la collaborazione tra i diversi team (CRM, SAP PI, SAP ECC);

• Cross Workstream Testing (CWT): verifica che le user story che costituiscono una funzionalità sviluppata e testata ottengano i risultati aziendali definiti dal Process Owner. È equivalente al System Integration Testing (SIT) e testa le funzionalità della soluzione complessiva che sono state progettate e costruite in modo integrato attraverso l’esecuzione dei processi aziendali End-to-End (E2E);

• Program Increment Testing: si verifica due volte nel processo di rilascio di un Minimun Viable Product (MVP):

– Alla fine dello sprint 4 nel Program Increment 1. Si tratta del test E2E di tutte le funzionalità contenute nell’incremento 1 rilasciato; – Alla fine dello sprint 4 nel Program Increment 2. Si tratta del test E2E di tutte le funzionalità contenute nell’incremento 1 più tutte quelle contenute nell’incremento 2, ovvero di tutti i processi di business definiti per il rilascio dell’MVP.

• Release Testing (User Acceptance Test): si tratta del test E2E di tutte le funzionalità rilasciate al cliente. Il Process Owner e i business user eseguono il test dei loro processi di business e se questi soddisfano i risultati di business specificati a monte del Program Increment dal Process

114

Owner saranno pronti per l’Operational Readiness Testing. In caso contrario, verranno aggiunte allo Sprint Backlog nuove user story per ridurre il gap;

• Operational Readiness Testing (ORT): rappresenta un componente del più ampio piano di rilascio teso a testare e verificare le attività chiave del piano stesso. Durante il Release Testing verranno eseguiti due tipi di test da pianificare durante l’Operational Readiness Testing:

– Day in the Life (DITL): è un test basato sul carico di lavoro giornaliero dell’utente. È volto a dimostrare che il sistema soddisfa l’aspettativa di utilizzo quotidiano da parte dei business user testando con volumi di dati giornalieri realistici;

– Performance E2E Test: assicura che l’applicazione soddisfi i requisiti prestazionali specificati e che sia in grado di sopportare il carico massimo (Peak Load) e di superare lo Stress Testing, il quale è il processo di determinazione della capacità del sistema di soddisfare alcuni requisiti non funzionali come ad esempio la capacità di mantenere un certo grado di efficacia in condizioni sfavorevoli.

• Post Deployment Validation: si tratta di attività di test del sistema dopo il rilascio della sua versione finale nell’ambiente di produzione. È condotto dai Process Owner e dai Key user mediante l’esecuzione degli script di test (un sottoinsieme degli script di test eseguiti durante l’UAT) che non richiede la creazione o la modifica di transazioni o master data, ma solamente la convalida delle interfacce-utente per i processi di business principali.

115

Figura 68: Le tipologie di test

Le tipologie di test, schematizzate in figura 68, che vengono eseguite in ogni Sprint (1-4) nelle fasi di Design/Build/Validate e successivamente di Test & Deploy sono:

• Assembly Testing: garantisce che i diversi componenti funzionino correttamente quando assemblati l’uno con l’altro. Il test delle interfacce consente di verificare che i dati corretti siano passati tra i vari componenti. Al termine del test, tutte le interfacce vengono eseguite al fine di dimostrare il loro funzionamento secondo le specifiche;

• Smoke Testing: conosciuto anche come Build Verification Testing, è una tipologia di test del software che comprende un insieme non esaustivo di test volti a garantire il funzionamento delle funzionalità più importanti. Il risultato di questo test viene utilizzato per decidere se uno sviluppo è sufficientemente stabile per procedere con ulteriori test. Questo deve essere eseguito ogni volta che un nuovo sviluppo viene rilasciato in qualsiasi ambiente: Development, Test, Staging, Production. Questi test dovrebbero essere automatizzati;

• Regression Testing: è un test volto a verificare che non vi siano impatti negativi sui processi di business dopo un nuovo rilascio o una modifica apportata al codice;

116

• System Integration Testing: viene eseguito all’interno dello Scrum Feature Testing e verifica che le funzionalità e le user story sviluppate e testate soddisfino i requisiti aziendali. In particolare tale test:

– Verifica che i requisiti di prodotto siano soddisfatti da ogni singola applicazione;

– È un test E2E dei requisiti del prodotto in tutte le applicazioni e piattaforme;

– È un test dell’architettura tecnica di prodotto.

• Security Testing: il test statico di sicurezza delle applicazioni (SAST) viene eseguito durante lo Unit Test da parte dello sviluppatore. Il test dinamico di sicurezza delle applicazioni (DAST) viene eseguito nell’ambiente di produzione dopo il rilascio della soluzione finale.

5.2.3 User Acceptance Test

Lo scopo di questo test, come anticipato nei paragrafi 4.7.3 e 5.2.2, è quello di coinvolgere i potenziali business user nell’esecuzione dei test dei propri processi aziendali (definiti dagli scenari e dai casi di test) al fine di assicurare che vi sia una facile implementazione dei nuovi sistemi: Microsoft Dynamics 365 for Field Service e Resco Mobile Application. I tester designati sono gli utenti del Back Office e i Key user per quanto riguarda i test che coinvolgono Microsoft Dynamics 365 for Field Service, i meccanici per quanto riguarda Resco Mobile Application. Gli utenti designati all’esecuzione dei test ricevono gli script di test contenenti la descrizione delle istruzioni da eseguire per completare il processo di business E2E.

5.2.4 Ambienti di sviluppo, test, controllo qualità e produzione

Durante il progetto di implementazione della soluzione, sono stati utilizzati i seguenti ambienti:

1. Ambiente di sviluppo: rappresenta l’ambiente in cui viene configurato e personalizzato il codice al fine di sviluppare l’applicazione che sarà rilasciata nei successivi ambienti;

2. Ambiente di test: è l’ambiente in cui vengono eseguiti tutti i tipi di test; 3. Ambiente di controllo qualità (anche detto staging/pre-production):

rappresenta l’ambiente che simula l’ambiente di produzione e che viene testato dal cliente con tutti i dati reali;

117

4. Ambiente di produzione: è l’ambiente in cui viene rilasciata la soluzione definitiva, pronta per essere utilizzata quotidianamente dal cliente.

5.2.5 Script di test

Con “script di test” si intende un elenco di tutte le azioni richieste per eseguire un test. Tipicamente uno script di test (test script) contiene dei passaggi detti test step che si prefiggono di descrivere come utilizzare il sistema, per esempio quali pulsanti premere e in quale ordine, per eseguire una determinata azione. Questi script includono anche specifici risultati attesi per ogni test step effettuato a sistema, come ad esempio l’osservazione di una modifica nell’interfaccia utente. Un semplice esempio di test step è:

“Clicca sul pulsante ‘X’” avente come risultato atteso “La finestra si chiude”. Se il tester segue attentamente i test step, lo script di test sarà coperto abbastanza da essere considerato testato.

I progetti di sviluppo dei software cambiano spesso durante il ciclo di vita: le pagine vengono ridisegnate, modifiche vengono apportate all’esperienza dell’utente, e nuove funzionalità vengono aggiunte. Per mantenerli efficaci nel tempo, quindi, i tester devono fare lo sforzo continuo di aggiornare gli script in modo che corrispondano al nuovo prodotto. Questo può richiedere molto tempo. Un altro svantaggio risiede nel fatto che gli script di test sono spesso progettati per testare ripetutamente una funzionalità specifica, nella stessa modalità ogni volta che il test viene nuovamente eseguito. Ciò significa che se sono presenti bug che non rientrano negli script di test preparati, questi non verranno trovati a meno che il tester in autonomia non esegua passaggi a sistema non contenuti negli script di test.

5.2.6 Casi di test

I casi di test rappresentano una tipologia di documentazione meno dettagliata degli script di test e costituiscono la descrizione di un’idea specifica da testare, senza andare a specificare nel dettaglio i passaggi da eseguire a sistema o i dati da utilizzare. Per esempio, un caso di test potrebbe essere:

118

Quest’ultimo non menziona come applicare il codice o se esistono più modi per applicare il codice. I test effettivi che copriranno questo test case possono variare di volta in volta, fornendo al tester la flessibilità per decidere come portare a compimento il test.

Questa flessibilità possiede una valenza sia positiva che negativa. È vantaggiosa quanto il tester ha familiarità con i test da eseguire e con il software in questione, conosce chiaramente ciò che è già stato testato, quali sono state le modifiche più recenti apportate al sistema e come gli utenti tipicamente lo utilizzano. In questo caso il tester adotterà un approccio tale da riprodurre sia i percorsi utente più comuni, che quelli più nascosti, e tale da massimizzare la probabilità di rilevare i bug.

D’altra parte, se il tester non dispone di una buona conoscenza di come il sistema viene utilizzato dagli utenti, i rischi più recenti associati al sistema stesso e come avviene la loro valutazione, potrebbe non possedere le informazioni o le competenze necessarie per eseguire i test richiesti per scovare i bug più importanti.

5.2.7 Scenari di test

Lo scenario di test è la tipologia di documentazione di più alto livello. Uno scenario di test è una descrizione di un obiettivo che un utente potrebbe dover affrontare quando utilizza il sistema. Un esempio potrebbe essere il seguente:

“Verificare che l’utente possa uscire con successo dal sistema chiudendo il programma”

In genere, uno scenario di test richiederà l’esecuzione dei test in modi differenti per garantire che lo scenario venga coperto in maniera soddisfacente. Basandosi sulla stretta descrizione, il tester potrebbe scegliere di chiudere il programma tramite l’opzione di menu, oppure tramite il task manager, oppure attraverso lo spegnimento diretto del computer. Poiché gli scenari di test forniscono poche informazioni su come completare il test, offrono il massimo livello di flessibilità al tester.

Come avviene per i casi di test, la flessibilità offerta dagli scenari è fonte di simili vantaggi e svantaggi. Le abilità di test e la conoscenza del sistema e del suo dominio di utilizzo lato utente rendono più facile per il tester veicolare lo scenario nelle idee di test più pertinenti e selezionare l’approccio che ha più senso seguire per rilevare i difetti più importanti. Questo lavoro è divertente e stimolante per un tester esperto, ma

119

può essere difficile o di dubbia efficacia per un principiante, a meno che questo non collabori con figure più esperte.

Un’attività eseguita in parellelo alla progettazione e allo sviluppo delle interfacce, come è rappresentato dalle linee temporali presentate in figura 65 e in figura 69, è stata quella di preparazione degli script di test.

Figura 69: Test script readiness

A partire da 5 scenari di test definiti dal project manager di Accenture dopo aver raccolto i requisiti del cliente, e successivamente suddivisi nei rispettivi otto casi di test, riportati in figura 70, il compito affidato è stato quello di stesura degli script di test corrispondenti, in seguito revisionati da una figura senior prima dell’approvazione finale del cliente.

120

Di seguito si riporta la descrizione di ciascuno scenario e i relativi casi di test:

1. Asset Installation/de-installation: si tratta dell’installazione o della disinstallazione (al termine del ciclo di vita o per una sostituzione in genere) di una o più attrezzature (tipicamente spillatori di birra) presso l’account:

• “Customer owned” asset installation: è l’installazione presso l’account di una o più attrezzature acquistate dal cliente e quindi di sua proprietà;

• Loaned asset installation and de-installation: si intende l’installazione e la disinstallazione di una o più attrezzature che vengono affidate in prestito o in leasing all’account ma la cui proprietà resta del produttore (cioè il cliente che ha acquistato Microsoft Dynamics 365 for Field Service);

• Installation of Bespoke material: si tratta dell’installazione di attrezzature ad hoc richieste su commessa dell’account che il cliente deve a sua volta acquistare da un fornitore;

• Non serialized asset installation and de-installation: consiste nell’installazione e nella disinstallazione delle attrezzature non serializzate. Sono definite attrezzature non serializzate quelle gestite tramite lo stesso numero di magazzino, a differenza di quelle serializzate che, invece, sono identificate da un numero di serie utilizzato ai fini della tracciatura;

2. Asset Repair: consiste nella riparazione di un’attrezzatura avente subìto un guasto;

3. Asset Lost & Found: entità definite Lost & Found indicano quelle attrezzature che sono state scoperte dal meccanico sul campo come Lost oppure Found e che possono essere create solamente tramite l’applicazione mobile Resco. Un’attrezzatura è detta Lost quando è creata a sistema per quell’account ma non è fisicamente presente. Il meccanico rileva questa discordanza e crea tramite dispositivo mobile un’entità Lost. Viceversa, un’attrezzatura è detta Found quando è presente fisicamente presso l’account ma non è creata a sistema. In questo caso il meccanico crea a sistema un’entità Found;

121

4. Claims management: è la gestione di un reclamo avvenuto da parte dell’account. Si tratta di creare a sistema un work order con tipologia “Claim”;

5. Mechanic call out: si tratta di un work order creato tramite dispositivo mobile dal meccanico in seguito a una visita effettuata presso l’account. Può scaturire dall’esigenza di installare una nuova attrezzatura, disinstallarne una obsoleta oppure dalla riparazione di un guasto scoperto in tempo reale.

Ciascuno degli otto casi di test pianificati si traduce nell’esecuzione di un certo numero di passaggi, test step, nell’ambiente di sviluppo del sistema. Come prima cosa è stato necessario apprendere le logiche di funzionamento di Microsoft Dynamics 365 for Field Service attraverso la consultazione del “Manuale dell’utente” e l’esplorazione del sistema stesso tramite licenza apposita. Infine, tra l’apprendimento del sistema e la scrittura degli script di test trova spazio la lettura del Business Blueprint (BBP), ovvero la documentazione riportante i diagrammi di flusso per ciascuno degli scenari di test e scritta durante lo Sprint 0 (chiamato Blueprint).

In particolare, per riprodurre gli scenari Asset Installation/de-installation, Claims management e Asset Lost & Found, il documento utilizzato è stato il seguente:

122

Per riprodurre lo scenario Asset Repair, il documento utilizzato è stato il seguente:

Figura 72: Scenario Repair

Infine, in figura 73 è riportato il documento utilizzato per riprodurre lo scenario Mechanic call out:

123

A titolo di esempio si riporta, di seguito, una parte dello script di test scritto per il caso di test “Customer owned” asset installation:

Figura 74: Script di test

Le parti più rilevanti dello script di test in figura sono:

• Test data: è il numero identificativo a sistema (ID) dell’account per il quale viene creato il work order;

• Test category: è costituito da uno o più test condition (test condition e test step hanno lo stesso significato) necessari per ottenere un determinato obiettivo. Ad esempio gli step dal due all’otto concorrono alla creazione di un work order; • Test condition: è il singolo test step;