Creazione del Manuale di Test

Introduzione al Manuale di Test funzionale generico

Il manuale di test rappresenta la guida fondamentale di AppQuality che viene fornita ai tester che partecipano alle campagne di test, al fine di consentire loro di avere una corretta comprensione del prodotto da testare e delle modalità con cui sia ammesso testarlo.

Il manuale di test segue strutture differenti in base alla tipologia di campagna da eseguire (Test funzionale, Testbook o Test Esperienziale). In questa guida si parlerà esclusivamente del Manuale di Test funzionale.

Il manuale di test viene la maggior parte delle volte consegnato al cliente per essere approvato: deve dunque contenere sempre un linguaggio appropriato, composto e rispettare il più possibile eventuali specifiche ricevute.

I template di riferimento per la scrittura del Manuale sono i seguenti:

• Template App
• Template Sito

La struttura del Manuale di Test

In un test funzionale il manuale è sempre costituito da una serie di casi d'uso, composti ognuno da un titolo e un contenuto. Un caso d'uso rappresenta un insieme di contenuti e istruzioni coerenti e autoconsistenti che i tester dovranno eseguire. Ogni caso d'uso può riportare una o più indicazioni, tuttavia è sempre bene che ogni caso d'uso si limiti a descrivere azioni il più possibilmente inerenti al proprio titolo.

Il titolo del caso d'uso deve essere progressivo e rispettare il formato "Use Case #: {testo}" a partire dal numero 0, che è sempre denominato Use Case 0: Setup. Ogni titolo deve permettere immediatamente di capire quali azioni possano esservi contenute.

• Use case 0: Setup
• Use case 1: Login
• Use Case 2: Completamento del checkout

Come use case finali, in base alle specifiche del cliente, è possibile aggiungere due ulteriori use case...

• Use case X: Test Esplorativo
• Use case Y: Stress Test

...oppure inserirli in un unico use case finale Use case X: Test esplorativo.

Come e cosa scrivere nello Use Case 0: Setup

Lo use case di setup è il più importante di tutto il manuale e solitamente anche quello che richiede maggiore attenzione. Al suo interno, oltre a un piccolo preambolo...

Benvenuto/a in questa nuova entusiasmante attività di Test! 

Durante questa attività l'obiettivo principale sarà testare il sito/l'app X. Ricordati di utilizzare il dispositivo con il quale sei stato selezionato: se non ti è più possibile utilizzarlo per il Test, contatta il Quality Leader.

...è necessario sempre indicare le modalità di accesso al prodotto da testare (link al sito o all'app, con specificazione del sistema operativo di riferimento).

Successivamente, è necessario indicare lo scope (cosa si può testare) e/o il focus del test (su cosa, tra le cose da testare, concentrarsi maggiormente). Alcuni esempi alternativi di scope e precisazione del focus sono riportati qui di seguito.

SCOPE

• Tutto il sito (concentrati sulla registrazione)
• Solo il checkout
• Tutto tranne i pagamenti
• Quanto presente e indicato nei casi d'uso

Subito dopo lo scope, è possibile marcare meglio cosa non sia nello scope, anche se questo costituisce una ripetizione di quanto già precisato nello scope. All'interno della sezione out of scope è inoltre possibile esplicitare eventuali bug noti. Se il test esplorativo o lo stress test non sono ammessi, allora è sempre necessario specificarlo.

OUT OF SCOPE (sezioni da non testare o bug da non caricare)

• Completamento del checkout
• La registrazione con Facebook non funziona
• Uso del device in orizzontale
• Test esplorativo / Tutto ciò che non è nei casi d'uso
• Stress Test

Come standard, è bene inoltre specificare una serie di regole di scrittura per i bug sia per facilitare il proprio lavoro di revisione dei bug, sia per permettere ai tester di avere chiare fin da subito le regole più comuni. Si può anche specificare una lista di ulteriori regole che sono spesso utili in presenza di tester inesperti o che possano aiutare meglio i tester a capire cosa scrivere in eventuali campi addizionali del bug form.

REGOLE DI SCRITTURA DEI BUG

Ogni bug che non rispetti le seguenti regole https://crowd.app-quality.com/it/regole-di-scrittura-dei-bug/ verrà rifiutato e penalizzato con la perdita di punti esperienza. Inoltre per questa campagna valgono

• Nel nome del bug inserisci tra parentesi quadre la sezione oggetto del test seguita dal titolo della segnalazione, ad esempio “[Profilo Personale] – Impossibile aggiornare mail”;
• Carica i bug in italiano;
• Nel campo addizionale "utenza" indica il codice del tuo contatore del gas

OUT OF SCOPE (sezioni da non testare o bug da non caricare)

• Completamento del checkout
• La registrazione con Facebook non funziona
• Uso del device in orizzontale

Non devono infine mancare dei chiari, corretti ed evidenti contatti per il supporto. Fai attenzione, specie se stai copiando il manuale di una campagna precedente o usando un modello, che i link siano quelli corretti.

SUPPORTO

• Canale Telegram per aggiornamenti rapidi sull'attività: LINK
• Contatto del Tester Leader per il supporto durante l'attività: LINK A TELEGRAM

Come e cosa scrivere nello Use Case X: Test Esplorativo

La scrittura di uno use case esplorativo è molto semplice, è infatti sufficiente spiegarne il significato in poche righe.

Giunto a questo punto puoi testare liberamente il prodotto da testare come preferisci, ripetendo i casi d'uso o esplorando altre aree, pur tenendo a mente le sezioni indicate come OUT OF SCOPE. Nella selezione del caso d'uso in cui hai trovato un bug, indica questo caso d'uso soltanto se la sezione o le azioni coinvolte non sono già presenti negli altri casi d'uso.

Come e cosa scrivere nello Use Case Y: Stress Test

La scrittura di uno use case di stress test è piuttosto semplice, è infatti sufficiente spiegare che è ammesso effettuare azioni insolite o particolari per andare alla ricerca di bug più rari.

Giunto a questo punto puoi stressare liberamente il prodotto da testare come preferisci, pur tenendo a mente le sezioni indicate come OUT OF SCOPE. Nella selezione del caso d'uso in cui hai trovato un bug, indica questo caso d'uso soltanto se la sezione o le azioni coinvolte non sono già presenti negli altri casi d'uso e riguardano appunto casi di utilizzo particolare del prodotto. 

Spesso è utile inserire alcuni esempi, ricordando però di esplicitare soltanto esempi di bug che verrebbero accettati nella specifica campagna.

• Inserisci dati insoliti o accentati nei campi
• Disattiva e riattiva la rete mentre usi l'app

Come e cosa scrivere i casi d'uso centrali

La scrittura dei casi d'uso centrali può essere di due tipi:

• ESPLORATIVA In questo caso il cliente non ha dato indicazioni particolari su cosa testare (e lo scope è tutto il prodotto, o una parte molto grande di esso). In tal caso si ha la libertà di esplorare il prodotto, intuire le sezioni più importanti e dividerle nei casi d'uso (con inserimento in coda di un caso d'uso esplorativo).
• BASATA SU SPECIFICHE DEL CLIENTE In questo caso il cliente ha dato indicazioni particolari su cosa testare. In tal caso i casi d'uso devono contenere l'insieme di cose che il cliente vuole testare, ma si può comunque aggiungere uno use case esplorativo o di stress test se questi rientrano nello scope.

Solitamente si tende a far rimanere il numero totale dei casi d'uso tra i 4 e i 10.

La scrittura dei casi d'uso deve seguire un filo logico (quando possibile) in modo da fornire una esperienza di test fluida. Non è necessario entrare troppo nel dettaglio delle azioni da compiere in quanto spesso, specie quando vengono testati dei siti, in quanto il layout cambia in base al device utilizzato e questo potrebbe portare alla segnalazione di bug non validi.

Dunque, è bene non fare riferimenti troppo specifici tipo "clicca l'icona in alto a sinistra", ma è meglio rimanere su un più generico "apri il menù", a meno che non si sia del tutto sicuri di un determinato comportamento/layout. Di norma, è quindi più conveniente indicare "quali azioni di flusso" portare a termine, piuttosto che il modo preciso in cui farlo, specie se il test ha carattere esplorativo e non basato su specifiche del cliente.

Scrittura, dubbi, commenti e revisione

La scrittura dei casi d'uso deve possibilmente seguire il formato del template in termini di titoli/colori/formattazione. Eventuali dubbi su alcuni punti o specifiche vanno comunicati al CSM commentando il manuale in riferimento alle parti coinvolte. In nessun caso devono essere lasciati commenti personali o inappropriati, in quanto la history del file mantiene comunque i vecchi commenti ed è raro che al cliente non venga consegnato l'originale.

Una volta concluso il manuale, è consigliabile eseguirlo su almeno un proprio dispositivo compatibile con i requisiti del test.

Incontro di bug durante la scrittura del manuale

Talvolta durante la scrittura di un manuale di test, specie per prodotti non in produzione e in stadi non avanzati, è possibile incontrare dei bug (anche bloccanti) che non consentano l'esecuzione di determinate operazioni (sia che il test sia esplorativo, che definito da specifiche del cliente).

Se il problema blocca solo una parte del test, inferiore al 15%, è possibile ignorare il bug e fare comunque eseguire l'azione al tester, che la segnalerà poi come bug, altrimenti è bene confrontarsi col CSM che deciderà se comunicare il problema al cliente, inserire il bug tra gli Out Of Scope o ignorare il problema.

Come fare in presenza di gruppi

Nel caso in cui sia necessario far eseguire ad un gruppo di utenti delle azioni, e ad altri azioni differenti, è necessario ripetere più volte i casi d'uso esplicitando nel titolo il gruppo di appartenenza, così che il cliente possa capire immediatamente la struttura del manuale.

• [GRUPPO 1] Use case 0: Setup web
• [GRUPPO 2] Use case 0: Setup app
• [GRUPPO 3] Use case 0: Setup in loco