Scrivere casi di test comprensibili per i tester business

Perché i tester business hanno bisogno di casi di test diversi

Un system test viene eseguito da persone che hanno costruito il sistema o lo conoscono bene. Uno user acceptance test viene eseguito da persone che lo usano: conoscono il lavoro, non la configurazione. Non sanno quale campo è nuovo, quale flusso gira in background o cosa intendeva lo sviluppatore.

Per questo un caso di test UAT deve funzionare per qualcuno che:

• conosce il processo di business a memoria, ma non le nuove schermate;
• ha qualche ora tra un'attività e l'altra, non una settimana;
• non dovrebbe mai dover indovinare se un passo è superato o fallito;
• quando un passo non è chiaro si ferma e aspetta, e perde tempo.

Ogni ora spesa su casi di test chiari fa risparmiare molte ore nelle giornate di test: meno domande, meno anomalie che si rivelano malintesi, e risultati di cui fidarsi al go/no-go.

Da user story e processi

I casi di test vengono da due fonti, e ti servono entrambe.

Le user story e i loro criteri di accettazione

Una user story dice cosa vuole fare qualcuno e perché: Come commerciale voglio convertire un lead qualificato, così da ottenere un account, un contatto e un'opportunità. I suoi criteri di accettazione dicono quando è completata. Ogni criterio di accettazione è un candidato per un passo o per un caso di test.

Verifica la copertura: ogni user story nell'ambito ha bisogno di almeno un caso di test. Una story senza è una lacuna, e le lacune si scoprono in produzione.

Processi di business, end-to-end

Le user story sono tagliate piccole per gli sviluppatori. Il business lavora in processi che attraversano molte story: lead to cash, quote to order, la gestione dei casi dall'email alla risoluzione. Una story può passare da sola mentre il processo si rompe nel passaggio di consegne tra due team.

Aggiungi quindi casi di test end-to-end che seguono un processo dall'inizio alla fine, tra ruoli diversi: il commerciale crea il preventivo, il manager lo approva, l'ordine passa all'amministrazione. Spesso sono i casi di test che contano di più per il business.

In UAT StudioLeggi le user story da Jira o Azure DevOps nella card User stories e spunta Only stories without test cases per vedere le lacune. Con il modulo AI test design, l'AI propone casi di test dalle tue story o dalla descrizione di un processo, anche sul modello della tua azienda. Nulla diventa un caso di test finché non lo approvi. Senza il modulo, Prepare with your own AI fornisce un prompt da incollare nell'AI della tua azienda; i passi contrassegnati con [CHECK] sono ipotesi da verificare.

Un obiettivo per caso di test

Un caso di test verifica uno scenario di business, con un solo obiettivo. Il titolo dice cosa ottiene il tester, con le parole del business:

• Convertire un lead con un account esistente
• Approvare un preventivo con uno sconto superiore al 20%
• Instradare un'email di un cliente noto alla coda giusta

Non Testare l'oggetto lead, e non Lead, opportunità e preventivi. Quando un caso di test ha più obiettivi, un solo errore li blocca tutti, e il risultato dice poco: cosa è fallito, e cosa funziona ancora?

Quanto è grande un caso di test?

Di norma un caso di test ha da tre a quindici passi e richiede a un tester da cinque a venti minuti. Se è molto più lungo, probabilmente ha più di un obiettivo: dividilo. Se è molto più corto, forse va unito a un caso vicino.

I casi di test end-to-end sono l'eccezione. Seguono un intero processo e possono essere più lunghi. Tienili, ma fai in modo che ogni parte del processo abbia anche un proprio caso di test più breve, così un errore è facile da localizzare.

Passi con un risultato atteso

Ogni passo ha due parti: un'azione (cosa fa il tester) e un risultato atteso (cosa dovrebbe succedere). Il risultato atteso è ciò che rende un passo verificabile. Senza, è il tester a decidere cosa è abbastanza buono, e due tester decidono in modo diverso.

Scrivere l'azione

• Un'azione per passo. Apri il lead e fai clic su Convert va bene; cinque clic in un passo no.
• Inizia con un verbo: apri, fai clic, compila, scegli, salva.
• Usa le etichette come appaiono sullo schermo, in grassetto o tra virgolette.
• Di' cosa fare, non come funziona il sistema all'interno. Salva il preventivo, non attiva il flusso di approvazione.

Scrivere il risultato atteso

• Di' cosa vede il tester: un messaggio, un valore in un campo, un nuovo record, uno stato.
• Sii specifico. L'opportunità è nella fase Qualification, non funziona.
• Indica cosa non deve succedere quando è importante: Non viene creato un secondo account.
• Per ciò che il sistema fa da solo, di' dove guardare: Il caso compare nella coda Benelux Support entro un minuto.

Dati di test e ruoli

Dati di test

I tester perdono più tempo a cercare i dati che in qualsiasi altra parte di un UAT. Inserisci i dati nel caso di test ovunque contino: quale cliente, quale prodotto, quale listino prezzi o price book, quale importo. Prepara quei dati nell'ambiente di test prima della prima giornata di test.

• Usa nomi che siano chiaramente dati di test, come Jansen Logistics (test).
• Dai a ogni tester i propri record quando modificano i dati, così due persone non modificano la stessa opportunità.
• Aggiungi valori ai limiti: uno sconto appena sotto e appena sopra la soglia, un campo obbligatorio vuoto.
• Non usare dati personali reali dei clienti quando puoi evitarlo.

Ruoli

In un CRM, ciò che un utente può vedere e fare dipende dal suo ruolo: un profilo e set di autorizzazioni in Salesforce, ruoli di sicurezza e una business unit in Dynamics 365. Un UAT dimostra che ogni ruolo può svolgere il proprio lavoro, e solo quello. Per questo ogni caso di test indica quale ruolo lo testa, e il tester accede con un utente di test che ha esattamente quel ruolo.

Non testare mai con un amministratore. Un amministratore vede e può fare tutto, così i problemi che un UAT dovrebbe trovare restano nascosti.

In UAT StudioOgni passo ha un'azione, un risultato atteso e facoltativamente dati di test. Ogni tester riceve un Test role e un Test account, mostrati in cima ai suoi test come Log in as …, e il ruolo compare accanto al suo nome in ogni anomalia che registra.

Priorità e rischio

Non c'è mai abbastanza tempo per testare tutto ugualmente bene. Contrassegna ogni caso di test in modo che quelli importanti siano testati per primi, e completati anche quando il tempo finisce.

Aggiungi accanto il rischio: quanto costa se qualcosa va storto dopo il go-live. Un prezzo sbagliato su una fattura è un rischio alto; un'etichetta sbagliata su un report è un rischio basso. A parità di priorità, i tester iniziano dal rischio alto.

Sii rigoroso con Must. Quando metà dei casi di test sono Must, l'etichetta non significa nulla: riservala a ciò di cui il business non può fare a meno. Concorda le priorità con i responsabili dei processi: decidono anche al go/no-go, dove i casi di test Must non superati contano di più.

In UAT StudioImposta Priority (Must, Should, Could) e Risk (High, Medium, Low) nell'editor o in una colonna durante l'importazione. Vengono letti anche i valori di altri strumenti: Critical e High diventano Must, Medium e Normal Should, Low Could. I tester vedono prima i loro casi di test Must, con il rischio alto per primo all'interno di ogni priorità.

Un esempio

Caso di test 12: Approvare un preventivo con uno sconto superiore al 20%

Priorità Must, rischio High. User story CRM-118. Ruolo: commerciale (passi da 1 a 3) e responsabile vendite (passi 4 e 5).

Nota cosa lo fa funzionare: un obiettivo nel titolo, un'azione per passo, un risultato atteso che un tester può verificare, i dati e il ruolo indicati, e un percorso negativo nel passo 3. Aggiungi un secondo caso di test per uno sconto sotto la soglia, che non dovrebbe richiedere approvazione.

Errori comuni

• Nessun risultato atteso, oppure funziona come previsto. Il tester deve indovinare cosa ci si aspettava.
• Linguaggio tecnico. Nomi di campi del database, nomi di oggetti, oppure verifica che il trigger scatti. Usa le parole sullo schermo.
• Troppi obiettivi in un caso di test. Un errore blocca il resto, e il risultato dice poco.
• Solo il percorso positivo. Aggiungi un campo obbligatorio lasciato vuoto, un valore sopra una soglia, un utente che non dovrebbe vedere un record.
• Dati di test mancanti. Apri un'opportunità: quale? In quale fase, con quali prodotti?
• Nessun ruolo. Il tester usa l'account che ha, spesso uno con troppi diritti.
• Copiati dal system test. Scritti per gli sviluppatori, con passi che i tester business non riescono a seguire.
• Tutto è Must. Allora niente lo è, e i test importanti non vengono fatti per primi.
• Scritti una volta, mai riletti. Gli script che nessuno ha controllato prima delle giornate di test sono pieni di etichette vecchie e menu sbagliati.

Falli rivedere a un key user

Prima delle giornate di test, chiedi a un key user del business di leggere i casi di test e di provarne due o tre nell'ambiente di test. Trova ciò che chi li ha scritti non vede: un passo che presuppone conoscenze, un'etichetta cambiata, un processo che funziona diversamente in un altro paese.

Verifica allo stesso tempo che ogni user story nell'ambito abbia un caso di test, che ogni ruolo nell'ambito testi qualcosa e che i dati di test esistano. Poi conserva i casi di test dopo il go-live: sono il tuo test di regressione per la prossima release del CRM.

In UAT StudioImporta i casi di test da Excel, Azure DevOps, Jira con Xray o Zephyr Scale, o TestRail, oppure scrivili nell'editor. La libreria di modelli, un modulo aggiuntivo per ogni piano a pagamento, ha script pronti per Salesforce e Dynamics 365 da adattare alla tua configurazione.

Gratuito

Per tutto il resto da organizzare prima, durante e dopo l'UAT, vedi la checklist UAT per il go-live di un CRM, disponibile anche come file Excel gratuito.