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.

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. 

asdasdasd

{{{numero}}} {{{titolo}}}

{{{contenuto}}}