Come scrivere casi di test con esempi

Che cos’è un caso di test?

Nel contesto del test del software, un test case si riferisce alla sequenza di azioni necessarie per verificare una specifica funzionalità o funzionalità. In sostanza, il test case descrive i passaggi, i dati, i prerequisiti e le postcondizioni necessari per verificare una funzionalità.

Presenterà particolari variabili che i QA devono confrontare i risultati attesi e effettivi per concludere se la funzione funziona come dovrebbe. I componenti del test case menzionano input, esecuzione e output/risposta attesi. Fondamentalmente, dice agli ingegneri cosa fare, come farlo e quali risultati sono accettabili.

L’obiettivo di scrivere casi di test

• Per convalidare caratteristiche e funzioni specifiche del software.
• Per guidare i tester attraverso la loro attività pratica quotidiana.
• Per registrare un catalogo di passi intrapresi, che possono essere rivisitati in caso di un bug popping up.
• Per fornire un progetto per progetti e tester futuri in modo che non debbano iniziare a lavorare da zero.
• Per aiutare a rilevare problemi di usabilità e lacune di progettazione nella fase iniziale.
• Per aiutare i nuovi tester e sviluppatori a raccogliere rapidamente i test, anche se si uniscono nel bel mezzo di un progetto in corso.

Test Standard del Formato Case

• ID di Test Case
• Scenario di Test

Passi

• Prerequisiti
• Dati di Test
• Attesi/Risultati previsti,
• Risultati Effettivi
• Test di Stato – Pass/Fail

Durante la scrittura di casi di test, ricordati di includere:

• Una descrizione ragionevole del requisito
• Una descrizione del processo di test
• Dettagli relativi alla configurazione di prova: versione del software in prova, punti dati, sistema operativo, hardware, nulla security di sicurezza, data, ora, prerequisiti, ecc.
• Qualsiasi documento correlato o allegato tester richiederà
• Alternativa ai prerequisiti, se esistono

Caratteristiche comuni dei casi di test

• Probabilmente essere rivisto e aggiornato regolarmente. I requisiti del software possono cambiare, a seconda dei cambiamenti nelle priorità aziendali o nelle preferenze dei clienti. Se i requisiti cambiano, i casi di test dovranno essere modificati di conseguenza. Il rilevamento di bug e le fasi di debug possono anche richiedere la modifica dei casi di test.
• Probabile che implichi il clustering. I casi di test in un singolo scenario di test di solito devono essere eseguiti in una sequenza specifica o in un gruppo. In questo caso, particolari pre-requisiti di un caso di test si applicheranno ad altri casi di test nella stessa sequenza.
• Probabilmente interdipendenti. Spesso, i casi di test possono dipendere l’uno dall’altro. Ciò è particolarmente vero per le applicazioni a più livelli con logica di business multi-tier.
• Probabilmente utilizzato da tester e sviluppatori. I casi di test sono utili sia per gli sviluppatori che per i tester. Ad esempio, quando gli sviluppatori risolvono bug, i casi di test possono essere piuttosto utili per replicare tale bug. In Test-Driven Development (TDD), gli sviluppatori creano casi di test per creare logica aziendale, coprire più scenari di test e iniziare a scrivere codice.

Esempio di test case

Creiamo un esempio di test case basato su uno scenario specifico. Ecco un caso di esempio.

• Test Case ID: # BST001
• Scenario di test: per autenticare un accesso utente riuscito su Gmail.com
• Passi di prova:
  • L’utente naviga verso Gmail.com.
  • Nel campo’ email’, l’utente inserisce un indirizzo email registrato.
  • L’utente fa clic sul pulsante ‘Avanti’.
  • L’utente inserisce la password registrata.
  • L’utente fa clic sull’accesso.’
• Prerequisiti: un ID Gmail registrato con un nome utente e una password univoci.
• Browser: Chrome v 86. Dispositivo: Samsung Galaxy Tab S7.
• Dati di test: nome utente e password legittimi.
• Risultati attesi / previsti: Una volta inserito nome utente e password, la pagina web reindirizza alla casella di posta dell’utente, visualizzando ed evidenziando nuove e-mail in alto.
• Risultati effettivi: come previsto
• Test Status – Pass/Fail: Pass

Best practice per la scrittura di casi di test

• Priorità chiarezza e trasparenza. Sii chiaro, conciso e assertivo nel descrivere ciò che il tester deve fare e quali risultati dovrebbero idealmente ottenere.
• Concentrarsi sui requisiti dell’utente finale durante la scrittura di casi di test di esempio. Mappare i casi di test per riflettere ogni aspetto del percorso dell’utente. Utilizzare il documento delle specifiche e il documento dei requisiti per farlo.
• Evitare la ripetizione. Se è possibile eseguire più test con lo stesso test case, utilizzare l’ID Test Case per fare riferimento al test case richiesto.
• Mantenere le fasi di test il più minime possibile. Idealmente, tenerlo a 10-15 passi, se possibile.
• Concentrarsi sul raggiungimento della massima copertura di prova. Mentre la copertura del test 100% è raramente realizzabile, un’alta percentuale può essere raggiunta con le giuste strategie.

  Per saperne di più: Come si fa a garantire la massima copertura di prova?

• Creare casi di test autopulenti. Ciò significa che i casi di test devono ripristinare l’ambiente di test in uno stato pristine e pre-test. I test non dovrebbero lasciare alcun residuo di se stessi nell’ambiente quando sono completati. Questo è un elemento integrante della gestione della configurazione. Per capire più in profondità: Cos’è la gestione della configurazione in DevOps?
• Casi di test di forma per test che restituiscono gli stessi risultati indipendentemente da chi li esegue. Assicurarsi che i test siano indipendenti.

Una volta formati i casi di test, i test corrispondenti devono essere eseguiti su browser, dispositivi e sistemi operativi reali. Ricorda che la frammentazione del dispositivo è una preoccupazione significativa per ogni sviluppatore e tester. Ogni sito web deve funzionare senza problemi su più combinazioni dispositivo-browser-OS. Con oltre 9000 dispositivi distinti utilizzati per accedere a Internet a livello globale, tutto il software deve essere ottimizzato per diverse configurazioni, finestre e risoluzioni dello schermo.

Prova a testare su Real Device Cloud gratuitamente

In questo stato, nessun emulatore o simulatore può replicare condizioni utente reali. Il software deve essere testato su dispositivi reali per funzionare in circostanze reali come batteria scarica, chiamate in arrivo, forza di rete debole e così via. Se un laboratorio interno non è accessibile, optare per un’opzione di test basata su cloud che offre dispositivi reali.

Cloud Selenium grid di BrowserStack offre oltre 2000 dispositivi e browser reali per test automatizzati. Ciò significa che gli utenti possono eseguire test su più dispositivi e browser reali semplicemente registrandosi, accedendo e selezionando le combinazioni richieste. I tester possono anche eseguire test di Cypress su oltre 30 versioni di browser reali su Windows e macOS. Rileva i bug prima che gli utenti lo facciano testando il software in condizioni reali con BrowserStack.

La creazione di casi di test ben strutturati e orientati ai risultati è fondamentale per eseguire test di successo. Inoltre, garantiscono una copertura completa dei test e forniscono un piano chiaro per il QAs da seguire. Utilizzare questo articolo per conoscere i fondamenti della creazione di casi di test efficaci e iniziare a eseguire test progettati per ottimizzare e fornire esperienze utente top-of-the-line.