Questo tutorial spiega che cos'è uno scenario di test, nonché l'importanza, l'implementazione, gli esempi e i modelli di uno scenario di test:
Qualsiasi funzionalità/caratteristica del software che può essere testata viene definita uno scenario di test. Nella stesura degli scenari di test si tiene conto della prospettiva dell'utente finale.
Questo tutorial vi aiuterà a rispondere alle domande: perché sono necessari gli scenari di test, quando si scrivono gli scenari di test e come si scrivono gli scenari di test.
Che cos'è uno scenario di test?
Consideriamo una situazione ipotetica: C'è un vasto oceano e bisogna attraversarlo da una riva all'altra. Ad esempio, da Mumbai, costa dell'India, a Colombo, costa dello Srilanka.
Le modalità di viaggio che si possono scegliere sono:
(i) Voli aerei: Prendere un volo per Colombo
(ii) Vie d'acqua: preferire una nave per recarsi a Colombo.
(iii) Ferrovie: prendere un treno per lo Srilanka.
Ora gli scenari di prova: Viaggiare dalla spiaggia di Mumbai a quella di Colombo è una funzionalità tutta da verificare.
Gli scenari di prova comprendono:
- Viaggiare in aereo,
- Viaggiare per vie d'acqua o
- Viaggiare in treno.
Questi scenari di test avranno dei casi di test.
I casi di test che possono essere scritti per i suddetti scenari di test includono:
Scenario di test: Viaggiare in aereo
I casi di test possono includere scenari come:
- Il volo si svolge secondo l'orario previsto.
- Il volo non rispetta l'orario previsto.
- Si è verificata una situazione di emergenza (forti piogge e temporali).
Allo stesso modo, è possibile scrivere una serie separata di casi di test per gli altri scenari rimanenti.
Passiamo ora agli scenari di prova tecnologici.
Tutto ciò che può essere testato è uno scenario di test. Si può quindi affermare che qualsiasi funzionalità del software in fase di test può essere suddivisa in più funzionalità più piccole e può essere definita uno "scenario di test".
Prima di consegnare un prodotto al cliente, è necessario valutarne la qualità. Lo scenario di test aiuta a valutare la qualità funzionale di un'applicazione software conforme ai requisiti aziendali.
Lo scenario del tester è un processo in cui il tester testa un'applicazione software dal punto di vista dell'utente finale. Le prestazioni e la qualità dell'applicazione software sono valutate in modo approfondito prima dell'implementazione nell'ambiente di produzione.
Importanza dello scenario di test
- Uno Scenario di test può avere più 'Casi di test'. Può essere immaginato come una grande immagine panoramica e i casi di test sono le piccole parti che sono importanti per completare il panorama.
- Si tratta di una dichiarazione di una sola riga e i casi di test comprendono una descrizione a tappe per completare lo scopo della dichiarazione dello scenario di test.
- Esempio:
Scenario di test: Effettuare il pagamento del servizio di taxi richiesto.
I casi di test saranno molteplici, come indicato di seguito:
(i) Metodo di pagamento da utilizzare: PayPal, Paytm, Carta di credito/debito.
(ii) Il pagamento è andato a buon fine.
(iii) Il pagamento effettuato non è andato a buon fine.
(iv) Il processo di pagamento si è interrotto nel mezzo.
(v) Non è possibile accedere ai metodi di pagamento.
(vi) L'applicazione si interrompe nel mezzo.
- Gli scenari di prova aiutano quindi a valutare l'applicazione software in base alle situazioni del mondo reale.
- Gli scenari di test, una volta determinati, aiutano a suddividere l'ambito dei test.
- Questa biforcazione è definita prioritizzazione e aiuta a determinare le funzionalità importanti dell'applicazione software.
- La verifica prioritaria delle funzionalità contribuisce in larga misura al successo dell'implementazione dell'applicazione software.
- Poiché gli scenari di test vengono classificati in base alle priorità, le funzionalità più importanti possono essere facilmente identificate e testate in base alla priorità. In questo modo si garantisce che la maggior parte delle funzionalità cruciali funzioni bene e che i difetti ad esse correlati vengano debitamente catturati e corretti.
- Gli scenari di test determinano il flusso del processo di business del software, rendendo possibile il test end-to-end dell'applicazione.
Differenza tra scenario di test e caso di test
| Scenario di prova | Casi di test |
|---|---|
| Lo scenario di prova è un concetto. | I casi di test sono le soluzioni per verificare tale concetto. |
| Lo scenario di prova è una funzionalità di alto livello. | I casi di test sono procedure dettagliate per testare le funzionalità di alto livello. |
| Gli scenari di test derivano dai requisiti e dalle storie degli utenti. | I casi di test sono derivati dagli scenari di test . |
| Lo scenario di test è "Quale funzionalità deve essere testata". | I casi di prova sono "Come testare la funzionalità". |
| Gli scenari di test hanno più casi di test. | Il caso di prova può essere associato o meno a più scenari di prova. |
| I singoli scenari di test non sono mai ripetibili. | Un singolo caso di test può essere utilizzato più volte in scenari diversi. |
| È richiesta una breve documentazione. | È richiesta una documentazione dettagliata. |
| Per mettere a punto uno scenario di prova sono necessarie sessioni di brainstorming. | È richiesta una conoscenza tecnica dettagliata dell'applicazione software |
| Risparmio di tempo in quanto non sono necessari dettagli minuziosi. | Richiede molto tempo, poiché è necessario curare ogni minimo dettaglio. |
| I costi di manutenzione sono bassi perché le risorse necessarie sono ridotte. | I costi di manutenzione sono elevati poiché le risorse richieste sono elevate |
Perché gli scenari di test sono indispensabili?
Gli scenari di test derivano dai requisiti o dalle storie dell'utente.
- Prendiamo l'esempio di uno scenario di test per la prenotazione di un taxi.
- Gli scenari possono essere le opzioni di prenotazione del taxi, i metodi di pagamento, la localizzazione GPS, la mappa stradale visualizzata correttamente o meno, i dettagli del taxi e dell'autista visualizzati correttamente o meno, e così via, tutti elencati nel modello di scenario di prova.
- Supponiamo che lo scenario di test sia di verificare se i servizi di localizzazione sono attivati e, se non sono attivati, di visualizzare il messaggio "Attiva i servizi di localizzazione". Questo scenario è stato tralasciato e non è elencato nel modello degli scenari di test.
- Lo scenario "Servizio di localizzazione" dà origine ad altri scenari di test ad esso correlati.
Questi possono essere:
- Il servizio di localizzazione è in grigio.
- Il servizio di localizzazione è attivo ma non c'è internet.
- Limitazioni ai servizi in loco.
- Viene visualizzata la posizione sbagliata.
- Manca un singolo scenario può significare perdere molte altre scenari cruciali o casi di test Questo può avere un grande effetto impatto negativo Questo comporta una forte perdita di risorse (scadenze).
- Gli scenari di test aiutano in larga misura a evitare test esaustivi Assicura che tutti i flussi di business cruciali e previsti vengano testati, contribuendo ulteriormente al collaudo end-to-end dell'applicazione.
- Inoltre, non è necessaria una descrizione molto più dettagliata dei casi di test, ma è sufficiente una descrizione di una riga su cosa testare.
- Gli scenari di test vengono scritti dopo sessioni di brainstorming In questo modo, la probabilità di perdere qualsiasi scenario (cruciale o minore) è minima. Questo viene fatto tenendo conto dei tecnicismi e anche del flusso commerciale dell'applicazione software.
- Inoltre, gli scenari di test possono essere approvati da un Business Analyst Client o da entrambi che hanno una conoscenza esplicita dell'applicazione in esame.
Gli scenari di test sono quindi una parte indispensabile dell'SDLC.
Implementazione di scenari di test
Vediamo l'implementazione degli scenari di test o come scrivere gli scenari di test:
- Si formano i requisiti di Epics/Business.
- Esempio di Epic Creare un account Gmail. L'epica può essere la caratteristica principale di un'applicazione o un requisito aziendale.
- Le epopee vengono suddivise in storie utente più piccole nel corso degli sprint.
- Le storie utente derivano dalle Epiche e devono essere baselineate e approvate dagli stakeholder.
- Gli scenari di test derivano dalle storie degli utenti o dai documenti BRS (Business Requirement Document), SRS (System Requirement Specification Document) o FRS (Functional Requirement Document) che vengono finalizzati e baselineati.
- I tester scrivono gli scenari di test.
- Questi scenari di test vengono approvati dal Team Lead, dal Business Analyst o dal Project Manager, a seconda dell'organizzazione.
- Ogni scenario di test deve essere legato ad almeno una storia utente.
- Devono essere identificati scenari di test positivi e negativi.
- Le storie utente comprendono Criteri di accettazione come :
- I criteri di accettazione sono un elenco di condizioni o lo stato di intenti dei requisiti del cliente. Nella stesura dei criteri di accettazione si tiene conto delle aspettative del cliente e anche delle incomprensioni.
- Questi sono unici per una storia utente e ogni storia utente deve avere almeno un criterio di accettazione che deve essere testabile in modo indipendente.
- I criteri di accettazione aiutano a determinare quali sono le caratteristiche che rientrano nell'ambito di applicazione e quali quelle che non rientrano nell'ambito di applicazione di un progetto. Questi criteri devono includere sia le caratteristiche funzionali che quelle non funzionali.
- Gli analisti di business scrivono i criteri di accettazione e il Product Owner li approva.
- Oppure, in alcuni casi, il proprietario del prodotto può scrivere lui stesso i criteri.
- Gli scenari di prova possono essere ottenuti dai criteri di accettazione.
Esempi di scenari di test
#1) Scenari di prova per l'applicazione Kindle
Kindle è l'applicazione che consente agli e-reader di cercare libri elettronici online, scaricarli e acquistarli. Amazon Kindle offre al lettore di e-book l'esperienza reale di tenere un libro in mano e leggerlo. Anche lo sfogliare delle pagine è ben simulato nell'applicazione.
Ora annotiamo gli scenari di test. ( Nota: Di seguito sono elencati alcuni scenari limitati per avere un'idea generale della scrittura dello scenario di test, da cui possono derivare più casi di test).
| Scenari di test # | Scenari di prova |
|---|---|
| 1 | Verificare se l'applicazione Kindle si avvia correttamente. |
| 2 | Verificare che la risoluzione dello schermo si adatti ai diversi dispositivi dopo l'avvio dell'applicazione. |
| 3 | Verificare che il testo visualizzato sia leggibile. |
| 4 | Verificare che le opzioni di ingrandimento e riduzione funzionino. |
| 5 | Verificare che i file compatibili importati nell'applicazione Kindle siano leggibili. |
| 6 | Verificare la capacità di memoria di Kindle App. |
| 7 | Verificare che la funzionalità di download funzioni correttamente. |
| 8 | Verificare che la simulazione di Page Turn funzioni correttamente |
| 9 | Verificare la compatibilità dei formati degli eBook con l'applicazione Kindle. |
| 10 | Verificare i font supportati dall'applicazione Kindle. |
| 11 | Verificare la durata della batteria utilizzata dall'applicazione Kindle. |
| 12 | Verificare le prestazioni di Kindle in base alla connettività di rete (Wi-Fi, 3G o 4G). |
Da ogni scenario di test sopra descritto si possono ricavare più casi di test.
#2) Criteri di accettazione per Google Docs
'Google docs' è un'applicazione basata sul web per creare, modificare e condividere documenti word, fogli di calcolo, diapositive e moduli. Tutti i file possono essere consultati online utilizzando un browser web con una connessione a Internet.
I documenti creati possono essere condivisi come pagine web o documenti pronti per la stampa. L'utente può impostare restrizioni su chi può visualizzare e modificare i documenti. Un singolo documento può essere condiviso in modo collaborativo e lavorato da persone diverse provenienti da località geografiche diverse.
Di seguito sono riportati alcuni scenari di test limitati per una comprensione generale. Gli scenari di test approfonditi per i documenti di Google possono essere un argomento a parte.
| Criteri di accettazione # | Criteri di accettazione |
|---|---|
| 1 | Word, Fogli o Moduli possono essere aperti senza errori. |
| 2 | Sono disponibili modelli per documenti, fogli e diapositive. |
| 3 | I modelli disponibili sono accessibili agli utenti. |
| 4 | Il modello utilizzato è modificabile (ad esempio: caratteri, dimensioni dei caratteri, aggiunta di testo, eliminazione di testo, inserimento di diapositive). |
| 5 | Se la connessione a Internet non è temporaneamente disponibile, il file può essere memorizzato localmente e caricato quando la connessione a Internet è disponibile. |
| 6 | Le modifiche apportate da più utenti non vengono sovrascritte. |
| 7 | Più utenti possono lavorare su un singolo documento. |
| 8 | Il lavoro svolto viene memorizzato se si perde la connessione a Internet durante il caricamento di un file. |
| 9 | Le restrizioni di condivisione sono applicate correttamente. |
| 10 | Gli utenti con restrizioni di visualizzazione non possono modificare i documenti. |
| 11 | I documenti possono essere pubblicati su Internet per il grande pubblico. |
| 12 | Le modifiche apportate ai documenti vengono salvate con la marca temporale e i dettagli dell'autore. |
Il numero di scenari di test sarà multiplo e molto elevato per Google Docs. In questi casi, generalmente, solo i criteri di accettazione vengono stabiliti e approvati dalle parti interessate e i membri del team lavorano su questi criteri di accettazione. Scrivere casi di test o piuttosto scenari di test può essere un compito esaustivo per applicazioni di grandi dimensioni.
Questi criteri di accettazione giocano un ruolo fondamentale nella pianificazione del processo iterativo e non dovrebbero mai essere trascurati. Definirli in anticipo evita sorprese o shock alla fine degli sprint o dei rilasci.
Dato una precondizione.
Quando per compiere un'azione.
Allora il risultato è atteso.
I formati Given, When e Then sono utili per specificare i criteri di accettazione.
Esempio di modello di scenario di test
| Utilizzare l'ID della storia | Scenario di prova ID # | Versione # | Scenari di prova | # N. di casi di test | Importanza |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Verificare se l'applicazione Kindle si avvia correttamente. | 4 | Alto |
| USID12.1 | TSID12.1.2 | Kin12.4 | Verificare la capacità di memoria di Kindle App. | 3 | Medio |
Conclusione
In qualsiasi test del software, la comprensione del ciclo di vita e la definizione degli scenari di test è un elemento molto significativo. La qualità del software può essere migliorata grazie a una buona base per gli scenari di test. Spesso, l'uso dei casi di test e degli scenari di test può essere scambiato.
Tuttavia, la regola generale è che lo scenario di test viene utilizzato per scrivere più casi di test o, per meglio dire, i casi di test derivano dagli scenari di test. Scenari di test ben definiti garantiscono un software di buona qualità.