Come scrivere casi di test

Non c’è dubbio che la scrittura di Test Case efficaci sia un’abilità indispensabile per gli specialisti di QA. Come ogni abilità può essere acquisita e migliorata. I principi principali e i consigli per una scrittura efficace dei Test Case saranno considerati in questo articolo.

Prima di iniziare, cerchiamo di capire bene cos’è il Test Case. Immaginate di dover testare alcune funzionalità dell’applicazione. Si dovrebbe avviare passo dopo passo la situazione in cui potrebbe essere implementata.

Per dirla semplicemente, il Test Case è un insieme di passi (azioni) ben progettati e facilmente comprensibili eseguiti per verificare una particolare caratteristica o funzionalità della vostra applicazione software. Tenete a mente “ben progettato” e “facilmente comprensibile”. Ha un senso importante come vedrete un po’ più avanti.

Quindi, ora possiamo iniziare. Qui divideremo il Test Case ai componenti e cercheremo di analizzare cosa dovrebbe essere fatto e cosa no per scriverlo con alta efficienza.

Test Case ID

Questo è un numero unico di Test Case nel sistema di gestione dei test o nel documento. Come regola tutti i moderni sistemi di gestione dei test come Jira, TestRail e Zephyr assegnano automaticamente l’ID al nuovo Test Case creato. Quindi, non c’è la possibilità di fare un errore con questo componente.

Ma, va notato, che su alcuni progetti è ancora usato Excel per i test. Ecco perché si dovrebbe sempre ricordare la regola: “Non ci sono Test Case con lo stesso ID nel sistema di gestione dei test. Anche questi sono Casi di Test da progetti finiti”.

Titolo del Caso di Test

Titolo forte è l’attributo obbligatorio del Caso di Test effettivo. Cosa significa? Le caratteristiche chiave del titolo forte sono: facile da capire e laconico. Oltre a questo, il Titolo del Caso di Test deve rappresentare il nome del modulo o l’area funzionale che si sta per verificare.

Immaginiamo di avere un compito di controllare cosa succederà se inseriamo simboli non validi come $,&, * nel campo “e-mail” del modulo di registrazione del Test Management System EasyQA. Secondo i principi sopra menzionati, il titolo del caso di test dovrebbe essere come: “Campo e-mail input non valido nel modulo di registrazione”.

Consideriamo l’esempio di un titolo non forte. “Campo e-mail “$&*” simboli di input nel modulo di registrazione di “EasyQA”. Qui abbiamo almeno due errori.

• L’eccessiva lunghezza del titolo. Non c’è bisogno di menzionare “EasyQA”, perché questo Test Case fa parte del Piano di Test per questo Test Management System. Quindi, tutti i casi di test sono interessati a “EasyQA”.
• Concretizzazione dei simboli speciali “$&*”. Anche altri simboli non validi potrebbero essere inseriti per l’esecuzione di questo tipo di test case. Quindi, “simboli non validi” è una definizione più adatta per questo titolo.

Alcuni sistemi di gestione dei test, incluso EasyQA, semplificano questo processo creando un campo modulo speciale per ogni Test Case.

Il piano di test è diviso in moduli, che includono particolari Test Case. Ecco perché è più facile creare un titolo forte per il caso di test.

Descrizione del caso di test

Prima di iniziare i test, dovresti menzionare tutti i dettagli su ciò che stai per testare. Essi sono: Dati di test da utilizzare, precondizioni (Presteps), dettagli dell’ambiente di test, strumenti di test.

Se fornisci i dati di test da utilizzare ovunque sia applicabile il caso di test all’interno della descrizione del caso di test o con il passo specifico del caso di test, aiuterai non solo te stesso, ma anche i tuoi colleghi-tester. È un grave errore scrivere i Test Case solo per se stessi.

Precondizioni (Presteps) descrivono diversi tipi di dipendenze dell’esecuzione del test:

• E’ necessaria una configurazione speciale
• Dipendenze da altri Test Case – il Test Case deve essere eseguito prima/dopo qualche altro Test Case
• Dipendenza dai dati dell’utente – da quale pagina l’utente deve iniziare il viaggio; l’utente deve essere loggato.

L’ambiente di test è una configurazione di software e hardware per i team di test per eseguire i casi di test. In altre parole, supporta l’esecuzione di test con hardware, software e rete configurati.

Quando si parla di strumenti di test, spesso si suggerisce il test automatizzato. Naturalmente sono precedentemente interessati a questo tipo di test. Ma ci sono anche semplici strumenti per i test manuali. Strumenti di mappatura mentale come Xmind, gestori di screenshot come Jing sono facili da usare anche per i nuovi arrivati nell’area QA. Comunque, se qualche strumento speciale è obbligatorio per i test, dovresti menzionarlo nella descrizione del Test Case.

Ovviamente, se lo stesso strumento è usato per l’esecuzione di qualche gruppo di Test Cases, sarebbe meglio descriverlo sul Modulo/SottoModulo di Test o anche nel Piano di Test.

C’è un tipo di errore tipico su cui dovresti concentrarti. Alcuni tester con meno esperienza confondono Steps con Presteps. Prendete nota, che Presteps è il modo per ottenere la situazione in cui l’esecuzione del Test Case potrebbe essere avviata. I passi sono il modo più efficace per ottenere il risultato effettivo dell’esecuzione del Test Case.

Per esempio, se dobbiamo testare le abilità funzionali dell’utente registrato, sarebbe un errore creare passi speciali di registrazione dell’utente per ogni Test Case nel modulo appropriato. La decisione giusta è quella di mostrarlo nei Prestep per tutti i Test Suite modulo di registrazione utente: l’utente deve essere registrato. Il processo di registrazione è verificato in una particolare Test Suite.

Come è stato detto prima, i passi sono la via verso il risultato atteso. Un’altra cosa da ricordare è che i passi in un Test Case efficace sono ben progettati e facilmente comprensibili. Questi due punti sono la base per capire come pianificare gli Steps per i vostri Test Cases.

I principali attributi di Steps ben progettati:

1. Quantità ottimale di Steps. Non c’è bisogno di scrivere passi aggiuntivi così come il passo “da mangiare”. Le cose che sembravano evidenti per voi, non potrebbero essere così chiare per i vostri colleghi.
2. Un Test Case copre solo una funzionalità indipendente. C’è un errore nel verificare diverse funzionalità in un solo Test Case.
3. Gli Step sono facilmente eseguibili.
4. Gli Step non dovrebbero coprire solo il flusso funzionale ma anche ogni punto di verifica che deve essere testato.

I principali attributi degli Step facilmente comprensibili:

1. Gli Step sono diretti. Non dovresti scrivere un saggio per descrivere i tuoi passi.
2. Espressione chiara. Dovresti evitare di usare ambiguità nei tuoi Test Case Steps.
3. Comprensibile anche per i principianti. I tuoi colleghi, che probabilmente non sono così esperti, dovrebbero essere in grado di capire come eseguire ogni passo.

Le prestazioni dell’applicazione dopo l’esecuzione dei passi di test di cui sopra vengono visualizzate nel risultato atteso. Quindi, prima di scrivere i Casi di Test, dovresti riconoscere pienamente quale pagina/schermo ti aspetti che appaia dopo il test e tutti gli aggiornamenti che ti aspetti come risultato da fare nei sistemi back-end o nel database.

Spero che tu ricordi che un Caso di Test copre una funzionalità indipendente. Ecco perché sarebbe un errore scrivere un Test Case con più di un risultato atteso.

Commenti/Post Condizioni non sono componenti obbligatori del Test Case, ma rendono davvero più alta l’efficienza del tuo Test Case. Qui puoi mettere informazioni aggiuntive utili come screenshot e descrizioni per fornire agli sviluppatori le informazioni di cui avranno bisogno per correggere qualsiasi difetto trovato.

Post Conditions sono anche usate per dare istruzioni guida per ripristinare il sistema al suo stato originale per non interferire con i test successivi. Per esempio, questo è abbastanza utile se si menzionano le modifiche da apportare a un Test Data per poterlo utilizzare per un Test Case successivo per la stessa funzionalità.

Diversi sistemi di Test Management offrono diverse varianti di campo Test Case. Il test case in EasyQA Test Management tool ha i seguenti:

1. Titolo
2. Modulo – per scegliere il modulo a cui si riferisce il nostro Test Case. – Se si preme Aggiungi caso nel modulo, questo campo sarà inserito di default.
3. Tipo – selezionare un tipo di caso di test dall’elenco a discesa secondo la seguente descrizione:

• Positivo è un caso di test che utilizza solo dati corretti.
• Negativo è un caso di test che utilizza non solo dati corretti.
• Limite è un caso di test che utilizza valori massimi/minimi.
• Integrazione è un componente del test di integrazione.
• UI è il test di un’interfaccia grafica utente.
• Localizzazione è il test di luoghi, lingue ecc.

1. Pre Steps
2. Steps
3. Expected Result

In questa immagine potete vedere il processo di aggiunta del test case con i campi compilati.

Una volta aggiunti i Casi di Test potete sceglierli con le caselle di controllo corrispondenti. Dopo aver scelto uno o pochi casi di test, potete spostarli dove volete. Sei in grado di modificarli o cancellarli.

Ora, quando hai qualche conoscenza teorica sulla scrittura dei Test Case, prova ad usarla per la decisione del prossimo compito.

Dati del compito:

1. C’è un sistema di gestione dei test “EasyQA” – https://geteasyqa.com/
2. Devi verificare la capacità dell’utente registrato di creare un nuovo piano di test per il progetto chiamato “Blogger” secondo le specifiche.
3. L’e-mail dell’utente è “[email protected]”, la password è “gEORGe52”

Consideriamo come creare ogni passo.

Ovviamente, l’ID unico sarà assegnato automaticamente dal Test Management System che usi.

In primo luogo, dovresti scegliere il titolo appropriato, il modulo e lo scenario di test per il Test Case. Naturalmente, il modulo potrebbe essere “Utente registrato”. E altri Test Case che testano la funzionalità dell’utente registrato saranno messi in questo modulo. Il titolo forte assomiglia a “Capacità di creazione di piani di test”. Lo scenario di test è positivo.

Come si deve controllare la funzionalità dell’utente registrato, è necessario visualizzare il modo di registrazione nei Pre Steps. Questi Pre Steps saranno gli stessi per tutti i Test Cases nel modulo “Utente registrato”.

Nel campo Steps devi mostrare come raggiungere il risultato atteso.

Determiniamo il Risultato Atteso come “L’utente registrato ha la possibilità di creare un Piano di Test”.

Possiamo vedere il risultato delle nostre azioni usando gli strumenti di gestione dei test di EasyQA.

Consideriamo alcuni tipici casi di test basati su diversi scenari.

I dati del compito sono quasi simili al compito precedente:

1. C’è un sistema di gestione dei test “EasyQA” – https://geteasyqa.com/
2. Il modulo “Sign Up” deve essere testato.
3. La lunghezza minima della password è di 6 simboli. La lunghezza massima è di 128 simboli
4. È possibile utilizzare solo lettere dell’alfabeto latino dalla A alla Z e cifre nei campi “Login”, “Password”, “Conferma password”.

Qui consideriamo alcune specifiche di questo tipo di processo di creazione di Test Cases.

Il modulo “Iscriviti” di EasyQA ha il seguente campo obbligatorio: “Nome”, “Cognome”, “Email”, “Password” e “Conferma password”. Oltre a questo, ci sono altri campi come “Azienda” e “Paese”, che non sono obbligatori, ma devono essere testati. Quindi, dovresti dividere il tuo modulo “Sign Up” Test Suite in sotto-moduli appropriati.

Prova ad analizzare alcuni scenari tipici: positivo, negativo e limite.

Secondo lo scenario positivo, l’utente non registrato inserisce solo dati validi in tutti i campi. Quindi non avrete problemi con la creazione di questo tipo di Casi di Test. Puoi vedere come potrebbe essere nell’immagine qui sotto.

Il risultato atteso per questo Test case è “L’inserimento di lettere latine e cifre è possibile nel campo “Password””.

Ma, cosa succederà se l’utente inserisce simboli non validi in uno dei campi precedentemente menzionati? Possiamo controllarlo eseguendo i Test Cases basati su Scenario Negativo. Infatti, ci sono molte varianti di input non valide. Potrebbe essere considerato in un articolo particolare. Qui ce ne sono solo alcune:

• “&%$” input di simboli
• Spaces input
• Empty field input
• Combinazioni di input di simboli non validi e non validi
• Altri casi input di lettere ecc.

Nell’immagine qui sotto è rappresentato un esempio di Test Cases negativo.

Il risultato atteso per questo Test case è “L’input non valido è impossibile nel campo “Password””.

Fate attenzione alla condizione – restrizione di lunghezza della password (6-128 simboli). È possibile essere registrati con solo 3 simboli di password? E con una password di 150 simboli? I Test Cases scritti con la tecnica di progettazione Boundary Value Testing ti danno le risposte a queste domande.

L’idea di base nel Boundary Value Testing è di selezionare i valori delle variabili di input al loro: minimo, appena sopra il minimo, appena sotto il massimo, massimo. Nel nostro esempio dovreste scrivere Casi di Test per situazioni con:

• 5 simboli password input
• 6 simboli password input
• 128 simboli password input
• 129 simboli password input.

Guardate l’immagine qui sotto per vedere come appare il Test Case scritto secondo questa tecnica.

Il risultato atteso per questo Test case è “Viene visualizzato il messaggio informativo “La lunghezza minima della password è di 6 simboli””.

Diverse funzionalità come la ricerca, la classificazione, la paginazione sono necessarie per essere testate. Anche questi Test Cases potrebbero essere scritti secondo gli scenari che abbiamo considerato prima. Essi verificano il normale funzionamento di:

• Campi di ricerca
• Bottoni di pagina
• Frecce
• Classificazione per nome (dalla A alla Z, dalla Z alla A)
• Classificazione per prezzo (prima il più basso, prima il più alto)
• Bottoni del menu della dashboard e della barra laterale ecc.

Torna al sistema di gestione dei test di EasyQA e scrivi un semplice caso di test per verificare la funzionalità di filtraggio del pulsante “Problemi chiusi”. Eccolo qui.

Il risultato atteso per questo caso di test è “Solo i problemi chiusi sono visualizzati nel menu della dashboard”.

I test di sicurezza sono spesso forniti da speciali strumenti di test automatici come Vega, Google Nogotofail, Wapiti ecc. Ma usando le tue capacità di attività mentale puoi scrivere semplici Test Case per controllare alcuni parametri di sicurezza del sito web. Torna di nuovo a EasyQA Test Management System. Puoi vedere un esempio di questo Test Case qui sotto.

Fai attenzione ai passi. Il risultato atteso per questo caso di test è “Il modulo EasyQA Sign In viene visualizzato dopo aver copiato/incollato l’URL da un browser all’altro”. Quindi, non c’è accesso all’account utente.

Ci sono molti strumenti di Test Management per aiutare i tester nel loro lavoro. EasyQA ti dà una vasta gamma di funzioni utili aggiuntive:

1. Esporta un piano di test preparato in formato CSV premendo un pulsante
2. Importa un piano di test preparato nel nostro sistema.
3. Visualizzazione dei casi di test in base a vari criteri:
4. Fare rapporti di crash
5. Costruire la distribuzione
6. Bug Tracking System
7. Eseguire i test
8. Generare rapporti
9. Integrazione rapida e facile con i vostri strumenti esistenti.

Per dirla semplicemente, EasyQA è più di un sistema di gestione dei test. È un ambiente di lavoro piacevole ed efficiente.

1. Tenete a mente, che i Test Case sono eseguiti anche dai tuoi colleghi
2. Usa un titolo forte
3. Presta attenzione ai Pre Steps e alle Precondizioni
4. Il Test Case copre una sola funzionalità e
5. Il Test Case ha un solo Risultato Atteso
6. Scrivi passi benben progettati e facilmente comprensibili
7. Non dimenticare di mettere tutte le informazioni utili nei Commenti o nelle Postcondizioni
8. Utilizzare illustrazioni e semplici strumenti di test se è necessario
9. Il Test Case deve essere riutilizzabile
10. Inizia a fare pratica

Vuoi scrivere Test Case efficaci? Inizia a farlo. E sarà nostro piacere aiutarti.

FACILE QA