La maggior parte dei casi di test fallisce prima ancora di individuare un singolo bug. Sono scritti come liste di controllo vaghe, prive di precondizioni, raggruppano più azioni in un unico passaggio o descrivono i risultati attesi in modo così approssimativo che due tester che leggono lo stesso caso potrebbero non essere d’accordo su cosa significhi “superato”. Il risultato: i bug sfuggono al controllo, le esecuzioni dei test non sono riproducibili e il controllo qualità diventa un collo di bottiglia invece che una rete di sicurezza.
Scrivere un buon caso di test non è tanto una questione di abilità di test, quanto piuttosto di progettazione della verifica. Nel settore dei servizi finanziari si parla di processo “maker-checker”. Nel comando nucleare si parla di “regola delle due persone”. Il principio è lo stesso: un’attività critica non dovrebbe mai basarsi su una singola azione non verificata. Un caso di test ben scritto infonde lo stesso rigore nel software. Separa ciò che ci si aspetta da ciò che si osserva, rendendo impossibile ignorare il divario tra i due.
Ti mostreremo come scrivere casi di test, perché sono importanti e come migliorarne la qualità nel tempo.
In breve
Un caso di test definisce i passaggi esatti, gli input e i risultati attesi necessari per verificare che una funzionalità/funzione funzioni correttamente. Ciascuno di essi deve avere un ID univoco, precondizioni e risultati attesi ben definiti, in modo che l’esito possa essere verificato. Questa guida illustra il processo di scrittura in sette fasi, presenta tre esempi pratici e spiega come mantenere affidabile una suite di test man mano che il prodotto evolve.
Cosa sono i casi di test?
Un caso di test è un documento strutturato che definisce i passaggi esatti, gli input, le precondizioni e i risultati attesi necessari per verificare se un determinato software si comporta correttamente. Non è un piano di test (che delinea la strategia di test) né uno script di test (un codice automatizzato che esegue i passaggi a livello di programmazione). Un caso di test è la specifica su cui si basano entrambi.
Esempio: stai testando la funzionalità di accesso di un'applicazione web. Un caso di test per questa funzionalità definirebbe i seguenti elementi:
- Azioni che descrivono i passaggi eseguiti dall’utente e le risposte attese dal sistema
- Condizioni che definiscono le regole che devono essere soddisfatte affinché il sistema possa procedere con ciascun passaggio
- Inserisci dati con valori di esempio per testare diversi risultati e verificare sia gli scenari di esito positivo che quelli di errore
Confronto tra casi di test manuali e automatizzati
L'intelligenza artificiale (IA) è ormai parte integrante della maggior parte dei flussi di lavoro di test. Secondo il rapporto "2026 State of Testing Report" di PractiTest, il 76,8% dei professionisti del testing utilizza l'IA nel controllo qualità (QA), con la creazione di casi di test (69,6%) e la manutenzione degli script (59,6%) come i due utilizzi più comuni. È proprio nei casi di test automatizzati che questo cambiamento si manifesta maggiormente, quindi vale la pena capire in che modo differiscono da quelli manuali.
| Parametro | Casi di test manuali | Casi di test automatizzati |
|---|---|---|
| Esecuzione | Eseguiti da un tester umano che segue una serie di passaggi documentati | Eseguiti tramite strumenti software, script o agenti IA |
| Velocità | Lento e dispendioso in termini di tempo, poiché gli esseri umani devono inserire manualmente i dati e verificare i risultati | È in grado di eseguire centinaia di casi di test contemporaneamente |
| Ripetibilità | Soggetto a errori umani e a interpretazioni incoerenti dei passaggi | Altamente ripetibili e coerenti quando gli script di test sono ben gestiti |
| Integrazione CI/CD | Difficile da integrare in pipeline di consegna in rapida evoluzione a causa di colli di bottiglia legati al fattore umano | Si integra direttamente nelle pipeline CI/CD per eseguire i test su ogni build |
| Manutenzione | Richiede aggiornamenti manuali dei documenti ogni volta che i requisiti cambiano | Richiede manutenzione tecnica per aggiornare gli script quando l’interfaccia utente o la logica subiscono modifiche |
| Ideale per | Test esplorativi | Test ripetitivi e di regressione |
Perché è importante scrivere casi di test ben strutturati
Individuerai le regressioni prima ancora che gli utenti aprano un ticket. Ogni modifica al codice comporta il rischio di compromettere il funzionamento di qualcosa che già funziona. Un caso di test ben scritto diventa un punto di controllo fisso che viene eseguito dopo ogni distribuzione. Quando uno sviluppatore rifattorizza il codice di accesso un anno dopo e compromette accidentalmente la gestione delle sessioni, è proprio quel caso di test a segnalarlo nell’ambiente di staging.
Trasforma il "superato/non superato" in un dato di fatto, non in un'opinione. Risultati attesi vaghi come "il sistema risponde in modo appropriato" costringono ogni tester a interpretare cosa significhi "appropriato". Due tester eseguono lo stesso caso, uno lo contrassegna come superato, l'altro segnala un difetto, e ora il team si ritrova a risolvere il disaccordo invece di occuparsi del software. Quando il risultato atteso recita “il sistema visualizza il messaggio di errore: ‘Password non valida’ e mantiene l’utente sulla pagina di accesso”, non c’è spazio per l’interpretazione. Il risultato corrisponde oppure no. Questa è la regola delle due persone messa in pratica: il caso di test è chi crea, il tester è chi verifica, ed entrambi devono parlare la stessa lingua.
Trasformi la conoscenza tacita in una risorsa riutilizzabile. Nella maggior parte dei team, l’ingegnere QA senior porta con sé una mappa invisibile di ogni caso limite, ogni soluzione alternativa, ogni “oh, assicurati di controllare anche X”. Quando quella persona va in ferie o cambia team, la mappa se ne va con lei. I casi di test documentati con precondizioni e valori limite espliciti preservano quella conoscenza in modo strutturato. Un nuovo tester che entra a far parte del team può prendere il caso di test TC_LOGIN_005 e testare il flusso di blocco dell’account dopo cinque tentativi fin dal primo giorno, senza dover chiedere a nessuno quale sia la soglia o come si azzeri il timer.
Isolate gli errori a passaggi precisi, non ad aree generiche. Quando un caso di test raggruppa “vai alla pagina, inserisci le credenziali e clicca su Invia” in un unico passaggio e il test fallisce, tutto ciò che sapete è che “qualcosa nel flusso di accesso non ha funzionato”. ” Quando ogni azione costituisce un passaggio a sé stante con il proprio risultato atteso, l’errore si individua al passaggio 4: “Fare clic su ‘Invia link di reimpostazione’ → messaggio di esito positivo atteso, ricevuto errore 500. ” Tale precisione riduce drasticamente i tempi di debug perché lo sviluppatore sa esattamente quale interazione ha triggerato il difetto, non solo in quale area di funzionalità/funzione cercare.
Potrai vedere cosa è coperto e quali sono i punti ciechi. Senza casi di test strutturati, la copertura dei test è solo una supposizione. Con essi, puoi mappare ogni caso a un requisito e individuare immediatamente le lacune. Se la tua funzionalità di reimpostazione della password presenta sei scenari (esito positivo, link scaduto, link riutilizzato, email non registrata, formato non valido, richieste multiple) e disponi di casi di test solo per tre di essi, la lacuna è evidente e quantificabile. È proprio questa visibilità a trasformare il testing da un semplice “l’abbiamo testato” a “ecco esattamente cosa abbiamo testato, ecco cosa non abbiamo testato ed ecco il rischio che stiamo accettando”.
Elementi costitutivi di un buon caso di test
Un caso di test utile non si limita a descrivere cosa testare. Ne descrive il contesto, i passaggi di esecuzione e il comportamento previsto del sistema, in modo che un altro tester, sviluppatore o product manager possa riprodurre il test e verificarne l'esito.
Gli elementi che compongono un caso di test sono:
- Identificatore univoco
- Scopo o descrizione
- Prerequisiti
- Passaggi di esecuzione
- Risultati attesi
- Risultati effettivi a scopo di confronto
Per l'esempio della funzione di accesso al sito web che abbiamo condiviso sopra, il tuo caso di test dovrebbe includere:
ID del caso di test: Ogni caso di test necessita di un identificatore univoco. Quando si testa una funzionalità/funzione, i team di controllo qualità spesso creano più casi di test che verificano condizioni simili. L’ID del caso di test aiuta a monitorarli, organizzarli e farvi riferimento facilmente durante il debug o la reportistica.
Esempio: TC_LOGIN_001
Descrizione: Spiega quale funzione viene verificata dal caso di test. Fornisce un breve riepilogo/riassunto affinché chiunque legga il caso di test ne comprenda immediatamente lo scopo.
Esempio: Verifica che un utente registrato possa accedere correttamente all’applicazione utilizzando credenziali valide.
Precondizioni: Le precondizioni descrivono lo stato del sistema richiesto prima dell'esecuzione del caso di test. Senza di esse, i tester potrebbero eseguire lo stesso test in condizioni diverse e ottenere risultati incoerenti.
Esempi:
- L'account dell'utente deve essere già presente nel sistema
- L'account dell'utente deve essere attivo e non bloccato
- La pagina di accesso dovrebbe essere accessibile
Passaggi: sono le azioni che un utente o un tester esegue per eseguire il caso di test. Ogni passaggio deve essere chiaro e sequenziale, in modo che chiunque nel team possa riprodurre il test.
- L'utente accede alla pagina di login
- L'utente inserisce un indirizzo email registrato
- L'utente inserisce la password corretta
- L’utente fa clic sul pulsante Login
Risultati attesi: definiscono ciò che il sistema dovrebbe fare se la funzionalità funzionasse correttamente.
- Se le credenziali sono valide, il sistema effettua l'autenticazione dell'utente
- L'utente viene reindirizzato alla dashboard
- Una sessione utente è stata creata con esito positivo
Se le credenziali non sono valide, il sistema dovrebbe visualizzare il messaggio di errore appropriato.
Risultati effettivi: questi riflettono le osservazioni del tester dopo l’esecuzione del caso di test. Se il comportamento osservato differisce dal risultato atteso, il problema viene registrato come difetto.
Esempio di osservazione:
- Hai inserito credenziali valide ma hai ricevuto un errore "Password non valida"
Ora mettiamo in pratica le tue competenze nella scrittura dei casi di test.
Lo sapevate? Solo il 2,1% dei team descrive le proprie pratiche di test dell’IA come ottimizzate, mentre oltre l’85% si trova ancora nella fase iniziale o sperimentale. L’utilizzo più comune è la generazione di casi di test (69,6%), non attività strategiche come l’identificazione dei rischi (19,9%).
Come scrivere casi di test (procedura di passaggio in passaggio)
La stesura di un caso di test prevede sette passaggi: analizzare i requisiti, creare un elenco di scenari, creare un piano per la struttura, scrivere i passaggi con i risultati attesi, allegare il contesto, far revisionare il caso, quindi eseguirlo e registrare i risultati.
Passaggio 1: Analizza i requisiti
Prima di scrivere il caso di test, cerca di comprendere quale sia la funzione prevista per quella funzionalità. È in questa fase che devi esaminare i documenti disponibili — PRD (documenti sui requisiti di prodotto), user story, specifiche delle funzionalità e documenti di progettazione — e identificare ogni singola funzionalità che deve essere verificata.
Esempio: stai sviluppando una funzionalità/funzione che consente agli utenti di reimpostare la propria password tramite email. Per creare un caso di test relativo a questa funzionalità/funzione, devi comprendere:
- Quale problema risolve questa funzionalità/funzione? Ad esempio, un utente può riottenere l'accesso al proprio account se dimentica la password?
- Quali azioni può compiere l'utente, ovvero richiedere un link di reimpostazione, riceverlo via email e impostare una nuova password?
- Cosa dovrebbe accadere quando vengono eseguite tali azioni, ovvero: il sistema invia un link di reimpostazione e consente all’utente di aggiornare correttamente la propria password?
- Ci sono delle restrizioni, ovvero il link scade dopo un determinato periodo di tempo o diventa non valido dopo un solo utilizzo?
- Esistono delle convalide o delle regole, ovvero la nuova password deve soddisfare requisiti specifici in termini di formato o lunghezza?
- C'è qualche funzione che risulta vaga o non ben definita? In tal caso, chiedi chiarimenti alle parti interessate
Questa chiarezza ti fornisce le basi per definire un obiettivo chiaro per il tuo caso di test.
Obiettivo: Verificare che un utente registrato sia in grado di reimpostare correttamente la propria password tramite email con esito positivo.
Passaggio 2: Identifica diversi scenari di test
Successivamente, crea un elenco degli scenari di test che devi convalidare. Uno scenario di test è una situazione di alto livello, che in genere si ramifica in più casi di test che coprono diversi input e risultati.
Per la funzionalità di reimpostazione della password, i tuoi scenari potrebbero essere simili ai seguenti:
- Reimpostazione con esito positivo: Verifica che un utente registrato possa richiedere un link di reimpostazione e impostare una nuova password
- Indirizzo e-mail non registrato: Verifica cosa succede quando viene inviato un indirizzo e-mail che non esiste nel sistema
- Link scaduto: Verifica che il sistema imponga il blocco dell'accesso quando si fa clic sul link di ripristino dopo la sua scadenza
- Link riutilizzato: Verifica che un link di reset già utilizzato non possa essere riutilizzato
- Nuova password non valida: Verifica che le password che non soddisfano i requisiti di formato vengano rifiutate
- Richieste di reset multiple: Verifica quale link rimane valido quando un utente ne richiede diversi di seguito
Ogni scenario qui descritto si tradurrà in uno o più casi di test che coprono input e condizioni specifici. Scomporre la funzionalità/funzione in questo modo garantisce una copertura di test sia per il comportamento previsto sia per i casi limite che gli utenti reali inevitabilmente incontreranno.
Per saperne di più: Come creare e implementare una lista di controllo per il controllo qualità
Passaggio 3: Pianifica il test e definisci la struttura dei casi di test
Per i test di regressione ripetitivi, è necessaria una struttura che consenta di documentare il caso di test e i relativi risultati in modo coerente. Un modello di caso di test ben definito garantisce tale coerenza e consente la riutilizzabilità senza dover ripartire da zero ogni volta.
Pianifica l’esecuzione dei test chiarendo questi elementi:
Chi effettuerà il test?
Quale ruolo o qualifica deve avere la persona che esegue questo test? A seconda della complessità del test e dell’intervento umano richiesto, assegnare i ruoli:
- Tester QA: test funzionali e di regressione, come la verifica dei flussi di accesso, la convalida dei moduli o le procedure di checkout
- Team di sicurezza: test relativi a vulnerabilità nell’autenticazione, nel controllo degli accessi o nell’esposizione dei dati
- Sviluppatore: Test unitari per singole funzioni, come l’hashing delle password o la generazione di token
Come verrà condotto il test?
- Su quali dispositivi e sistemi operativi verrà eseguito il test?
- Quali strumenti o framework di test verranno utilizzati?
- Il test verrà eseguito manualmente o tramite un agente IA?
- Come verranno registrati i risultati: in uno strumento di gestione dei test, in un foglio di calcolo o in un bug tracker?
Quali sono i prerequisiti?
Elenca tutte le condizioni che devono essere soddisfatte prima del passaggio 1 e assicurati che ciascuna di esse sia verificabile dal tester:
Esempio:
- Esiste un account utente con l'email “test@example.com”
- L'utente è stato disconnesso dal sistema
- Il servizio di email è attivo e in grado di recapitare i messaggi
- L'ambiente di test è accessibile e in esecuzione
Quali dati di test verranno utilizzati?
Definisci i valori di input esatti necessari per eseguire il test: dati validi, dati non validi e valori limite.
Esempio:
- Valido: indirizzo email registrato “test@example.com”, password conforme ai requisiti di formato
- Non valido: email non registrata, password con un numero di caratteri inferiore al limite minimo
- Condizione limite: password che rispetta esattamente i limiti minimo e massimo di caratteri
Fase 4: Scrivi i passaggi di test e i risultati attesi
Suddividi il processo di esecuzione in passaggi sequenziali. Utilizza una terminologia coerente e assicurati che ogni passaggio preveda una sola azione. Quando definisci i passaggi, descrivi anche il risultato atteso e cosa costituisce un esito positivo o negativo.
Proseguendo con il nostro flusso di reimpostazione della password, ecco come si presenterebbero i passaggi di test:
| Passaggi | Risultato atteso |
| Vai alla pagina di accesso | La pagina di accesso si carica con un link cliccabile “Password dimenticata” |
| Clicca su “Password dimenticata” | L'utente viene reindirizzato alla pagina di richiesta di reimpostazione della password |
| Inserisci l'indirizzo email nel campo "Email" | L'indirizzo di email è valido e non presenta errori di convalida |
| Clicca su “Invia link di reimpostazione” | Viene visualizzato il messaggio di conferma: “Link di reimpostazione inviato a test@example.com” |
| Apri il link di reimpostazione contenuto nell'email | L'utente viene reindirizzato alla pagina di creazione della nuova password |
| Inserisci una nuova password valida | Il campo "Password" accetta l'immissione di dati senza generare errori |
| Clicca su “Reimposta password” | Viene visualizzato un messaggio di conferma e l'utente viene reindirizzato alla pagina di accesso |
Ora definisci i passaggi e i risultati attesi per gli scenari alternativi (discussi in precedenza). Spiega cosa succede quando l’utente inserisce un indirizzo email non valido o la password non soddisfa i criteri prestabiliti.
Bonus: Ecco come puoi automatizzare la documentazione utilizzando l'IA per tutti i tuoi casi di test.
Passaggio 5: Includi gli allegati pertinenti
Includi documenti o allegati pertinenti che aiutino i tester a eseguire il caso di test nel contesto completo e senza ambiguità. Questi possono includere:
- Screenshot annotato dell’interfaccia utente nei passaggi chiave
- Registrazioni dello schermo che mostrano come eseguire il test in diversi scenari e quali risultati aspettarsi
- Log di sistema o file di configurazione per aiutare a diagnosticare i problemi del backend quando un test fallisce
- Documenti dei requisiti che mappano il caso di test con la user story o i criteri di accettazione che esso verifica
- File di dati di test contenenti input validi e non validi, oppure dati generati come numeri di carte di credito, indirizzi casuali o credenziali di utente
- Predisponi la documentazione relativa alla versione specifica del software, all’hardware richiesto, al sistema operativo e a eventuali autorizzazioni di sicurezza necessarie
- Per il collaudo delle API, specifiche OpenAPI o documentazione degli endpoint che descriva in dettaglio i metodi di richiesta, i parametri e i codici di stato previsti
Passaggio 6: Fai revisionare il caso di test
Condividi il caso di test redatto con un collega o con un responsabile senior del controllo qualità prima di eseguirlo. Durante la revisione, verifica che:
- Il caso di test è esaustivo e copre tutti i possibili scenari derivanti dai requisiti
- I passaggi sono chiari e rappresentano in modo sequenziale il flusso di esecuzione effettivo
- Ogni risultato atteso indica un esito osservabile (un messaggio, un reindirizzamento, un codice di stato), non una qualità come “funziona correttamente”
- I dati di test e le precondizioni sono completi e accurati
- Qualsiasi ipotesi formulata durante la stesura viene documentata in modo esplicito
Passaggio 7: Eseguire i test e registrare i risultati
Esegui il test e registra il risultato effettivo a fronte di ciascun risultato atteso. Contrassegna un test come superato o fallito in ogni passaggio. Per ogni passaggio fallito, segnala immediatamente un bug e collegalo al caso di test. Inoltre, se si verifica un comportamento inaspettato che non è chiaramente né un superamento né un fallimento, annotalo nel campo dei commenti per un'ulteriore revisione.
Per saperne di più: Come utilizzare l'IA per la garanzia della qualità
Esempi di scrittura di casi di test
Questi tre esempi mostrano come la stessa struttura dei casi di test si adatti a diversi tipi di test software. Ciascuno di essi utilizza i componenti e il formato dei passaggi illustrati in precedenza in questa guida, ma la complessità, i dati di test e le modalità di errore variano a seconda di ciò che si sta verificando.
Esempio 1: Flusso di checkout nell’e-commerce (interfaccia utente, flusso di lavoro in più passaggi)
Il team di controllo qualità di un rivenditore online sta testando l’esperienza di checkout in vista dei saldi natalizi. Il flusso si articola su più pagine: carrello → spedizione → pagamento → conferma. La sfida principale in questo caso è rappresentata dalla dipendenza dallo stato: ogni passaggio dipende dal corretto completamento di quello precedente e i dati di test (contenuto del carrello, indirizzo di spedizione, modalità/metodo di pagamento) devono essere mantenuti in tutti i passaggi.
Tester: Rahul D.
Data dell'esame: 09/03/2026
ID caso di test: TC_CHECKOUT_003
Descrizione: Verificare che un utente che ha effettuato l'accesso possa completare un acquisto utilizzando una carta di credito salvata e la spedizione standard.
Prerequisiti:
- L'account utente esiste e presenta almeno una carta di credito registrata e un indirizzo di spedizione salvato
- È disponibile almeno un elemento, che è stato aggiunto al carrello
- L'ambiente di test è in esecuzione su Chrome 128, macOS
| Passaggio | Risultato atteso | Risultato effettivo | Superato/Non superato |
| Vai alla pagina del carrello | Il carrello mostra correttamente l'elemento, la quantità e il subtotale | Come previsto | Supera |
| Clicca su “Procedi al checkout” | Caricamento della pagina di spedizione con l'indirizzo salvato in stato di selezione | Come previsto | Supera |
| Seleziona “Spedizione standard” e clicca su Continua | La pagina di pagamento viene caricata mostrando il totale dell'ordine con le spese di spedizione aggiunte | Come previsto | Supera |
| Conferma i dati della carta di credito salvati e clicca su “Effettua l'ordine” | Viene visualizzata la pagina di conferma dell'ordine con il numero d'ordine, il riepilogo degli elementi e la data di consegna prevista | La pagina di pagamento si ricarica con l'errore: “Impossibile elaborare il pagamento” | Errore |
Riepilogo dei risultati: Il flusso di checkout gestisce correttamente il passaggio dal carrello alla spedizione, ma l'elaborazione del pagamento fallisce con le carte di credito salvate. Difetto registrato: la ricerca della carta tokenizzata va in timeout quando il gateway di pagamento impiega più di 3 secondi a rispondere.
Esempio 2: Endpoint API REST (senza interfaccia utente, convalida di input/output)
Un ingegnere backend sta testando l’endpoint API “Crea utente” prima che venga utilizzato dal team front-end. Non c’è alcuna interfaccia su cui cliccare: il caso di test verifica direttamente i payload delle richieste, i codici di risposta e la persistenza dei dati. La sfida principale consiste nel testare il contratto tra i sistemi, non l’esperienza utente.
Tester: Sarah S.
Data dell'esame: 09/05/2026
ID caso di test: TC_API_USER_001
Descrizione: Verifica che una richiesta POST a /api/v1/users crei un nuovo utente e restituisca la risposta corretta.
Prerequisiti:
- L'ambiente di test API è attivo e accessibile
- È stato generato un token di autenticazione con autorizzazioni di amministratore, che risulta valido
- Nel database non esiste alcun utente con email “newuser@testdomain.com”
| Passaggio | Risultato atteso | Risultato effettivo | Superato/Non superato |
| Invia una richiesta POST a /api/v1/users con un payload valido: { "name": "Test User", "email": "newuser@testdomain.com", "ruolo": "viewer" } | La risposta restituisce 201 Created con un corpo JSON contenente l'ID utente, il nome, l'email e il ruolo | 201 restituito con corpo corretto | Supera |
| Invia nuovamente la stessa richiesta POST con l'email identico | La risposta restituisce un codice di stato 409 (Conflitto) con il messaggio: “Esiste già un utente con questa email” | Risposta 200 OK; utente duplicato creato | Errore |
| Invia un POST con il campo “email” mancante | La risposta restituisce un codice di stato 400 (Richiesta non valida) con l'errore di convalida: "L'email è obbligatoria" | 400 restituito come previsto | Supera |
| Esegui la query GET /api/v1/users/{id} utilizzando l'ID del passaggio 1 | La risposta restituisce un codice 200 OK con i dettagli dell'utente che corrispondono al payload originale | Come previsto | Supera |
Riassunto dei risultati: L'endpoint crea correttamente gli utenti e convalida i campi obbligatori, ma non garantisce l'unicità degli indirizzi email a livello di database. Sono stati creati record duplicati senza che venisse segnalato alcun errore. Difetto registrato con gravità: Alta.
Esempio 3: Controllo degli accessi basato sui ruoli (sicurezza, limiti delle autorizzazioni)
Un team di sicurezza sta verificando se l’applicazione limiti correttamente le azioni in base ai ruoli degli utenti prima di un audit di conformità. La sfida principale consiste nel fatto che non si sta verificando se una funzionalità/funzione funzioni, ma se venga correttamente negata. Il risultato atteso per la maggior parte dei passaggi è un blocco, non un esito positivo.
Tester: Marcus L.
Data dell'esame: 09/08/2026
ID del caso di test: TC_RBAC_002
Descrizione: Verifica che un utente con il ruolo "Visualizzatore" non possa creare, effettuare la modifica o eliminare progetti.
Prerequisiti:
- Esistono due account: uno con il ruolo “Amministratore” e uno con il ruolo “Viewer”
- Nell'area di lavoro è presente almeno un progetto, creato dall'amministratore
- L'utente ha effettuato l'accesso su Firefox 130, Windows 11
| Passaggio | Risultato atteso | Risultato effettivo | Superato/Non superato |
| Vai alla pagina Progetti | L'utente visualizza l'elenco dei progetti in modalità di sola lettura; il pulsante "Crea progetto" è nascosto o disabilitato | Il pulsante è visibile ma disattivato | Supera |
| Prova a fare clic su “Crea progetto” | Il sistema impedisce l'operazione; il modulo per il nuovo progetto non viene caricato | Nessun modulo caricato; il tooltip mostra “Non disponi dell’autorizzazione necessaria” | Supera |
| Apri un progetto esistente e prova a effettuare una modifica sul titolo | Il campo "Titolo" non è modificabile, oppure il sistema blocca il salvataggio | Il campo "Titolo" era modificabile; le modifiche sono state salvate con esito positivo | Errore |
| Prova a eliminare il progetto tramite il menu con i tre puntini | L'opzione "Elimina" è nascosta oppure c'è un blocco dell'azione a causa di un errore di autorizzazione | L'opzione "Elimina" non ha una visibilità adeguata nel menu | Supera |
Riassunto dei risultati: le autorizzazioni di creazione ed eliminazione sono correttamente limitate per gli utenti con ruolo "Visualizzatore", ma le autorizzazioni di modifica non vengono applicate a livello di campo. Un utente con ruolo "Visualizzatore" può modificare i titoli dei progetti nonostante disponga di un accesso in sola lettura. Difetto registrato con gravità: Critico (ostacolo alla conformità).
Quali sono gli strumenti migliori per la gestione dei casi di test?
I casi di test possono essere gestiti in uno strumento dedicato al controllo qualità (TestRail, Zephyr), in uno strumento generico di gestione dei progetti (ClickUp, Jira) o in un foglio di calcolo; la scelta giusta dipende dal fatto che abbiate bisogno di funzionalità di esecuzione integrate o semplicemente di monitoraggio.
ClickUp
ClickUp for Software Teams è una piattaforma di project management in cui i casi di test vengono gestiti come attività insieme agli sprint, ai bug e alle richieste pull a cui si riferiscono. Non si tratta di uno strumento dedicato alla gestione dei test, ma la sua struttura flessibile delle attività consente ai team di creare flussi di lavoro per i casi di test utilizzando stati, campi e tipi di attività personalizzati senza bisogno di uno strumento separato.
Funzionalità principali di ClickUp
- Gerarchia flessibile per organizzare i casi di test in Spazi, Cartelle ed Elenchi con campi personalizzati per tipo di test, priorità e ambiente
- Oltre 15 viste di ClickUp (bacheca, elenco, tabella) per monitorare l'esecuzione dei test in base allo stato, all'assegnatario o allo sprint
- Documenti per conservare i PRD, i piani di test e le guide alla configurazione dell’ambiente accanto ai casi di test a cui fanno riferimento
- Chat integrata per la comunicazione tra il team QA e gli sviluppatori senza dover passare a Slack o all'email
- Riepiloghi delle attività basati sull’intelligenza artificiale tramite ClickUp Brain per una rapida comprensione del contesto durante le revisioni degli sprint
Limiti di ClickUp
- Nessun motore di esecuzione dei test nativo
- I report specifici per i test (copertura per requisito, percentuale di superamento per ciclo) richiedono dashboard personalizzate anziché reportistica di controllo qualità predefinita
Prezzi di ClickUp
Valutazioni e recensioni su ClickUp
- G2: 4,6/5 (oltre 14.100 recensioni)
- Capterra: 4,6/5 (oltre 4.600 recensioni)
Cosa dicono gli utenti reali di ClickUp?
Ecco cosa dice un recensore di G2:
Ciò che apprezzo di più di ClickUp è che riunisce tutto in un unico posto. Attività, scadenze, note e aggiornamenti risiedono tutti nello stesso sistema, il che riduce il continuo passaggio da uno strumento all’altro. Apprezzo anche la flessibilità. Possiamo personalizzare stati, campi e visualizzazioni in base al modo in cui il nostro team lavora effettivamente. Ciò rende più facile mantenere l’organizzazione e offre una chiara visibilità su chi è responsabile di cosa e sullo stato dei progetti in qualsiasi momento.
Ciò che apprezzo di più di ClickUp è che riunisce tutto in un unico posto. Attività, scadenze, note e aggiornamenti risiedono tutti nello stesso sistema, il che riduce il continuo passaggio da uno strumento all’altro. Apprezzo anche la flessibilità. Possiamo personalizzare stati, campi e visualizzazioni in base al modo in cui il nostro team lavora effettivamente. Ciò rende più facile mantenere l’organizzazione e offre una chiara visibilità su chi è responsabile di cosa e sullo stato dei progetti in qualsiasi momento.
Ideale per: un responsabile QA che desidera trasformare un test fallito in un ticket di bug per lo sviluppatore con un solo clic, con la richiesta di pull, i passaggi di test e lo sprint tutti visibili dalla stessa attività.
Salta questo passaggio se: il tuo ciclo di test è prevalentemente automatizzato. Se l’80% della tua suite viene eseguita da una pipeline di CI, hai bisogno di uno strumento che acquisisca i risultati dell’esecuzione, non di uno in cui sia un operatore a aggiornare lo stato.
TestRail
TestRail è una piattaforma dedicata alla gestione dei test, progettata per i team di controllo qualità che necessitano di un controllo strutturato sull’intero processo di test. Gestisce l’intero ciclo di scrittura, esecuzione e reportistica dei casi di test, con integrazioni DevOps e CI/CD che forniscono i risultati.
Funzionalità principali di TestRail
- Gestione centralizzata dei casi di test e delle suite di test con casi di test riutilizzabili in tutti i progetti
- Piani di test e attività cardine per organizzare e programmare le esecuzioni dei test nell’ambito degli sprint e delle versioni
- Reportistica dettagliata con analisi della copertura, monitoraggio dello stato di avanzamento e cronologia delle esecuzioni
- Integrazioni con Jira, GitHub, Jenkins, Azure DevOps e oltre 20 altri strumenti DevOps
- API REST per l’automazione delle attività e la sincronizzazione dei dati di test con sistemi esterni
Limiti di TestRail
- In assenza di requisiti nativi o di sistemi di monitoraggio dei problemi, i team devono affidarsi a strumenti esterni come Jira, il che può compromettere la tracciabilità
- L'organizzazione basata su cartelle diventa difficile da gestire man mano che i repository di test raggiungono le migliaia
Prezzi di TestRail
- Professionale: 39 $ al mese per postazione
- Enterprise: 78 $ al mese per postazione
Valutazioni e recensioni su TestRail
- G2: 4,4/5 (oltre 600 recensioni)
- Capterra: 4,3/5 (oltre 160 recensioni)
Cosa dicono gli utenti reali di TestRail?
Ecco cosa dice un recensore di G2:
Ciò che apprezzo di più di TestRail è che offre al nostro team di controllo qualità un ambiente sicuro e ben organizzato per gestire piani di test, casi di test ed esecuzioni dei test. Apprezzo la semplicità con cui è possibile strutturare e implementare suite di test, nonché riutilizzare casi di test creati in precedenza. Le integrazioni con Jira e gli strumenti CI/CD hanno reso il nostro flusso di lavoro più coerente e più facile da monitorare. La possibilità di monitorare in tempo reale lo stato di avanzamento dei test e la copertura è stata incredibilmente utile per la pianificazione degli sprint e la reportistica. Nel mio lavoro quotidiano come ingegnere QA, l’utilizzo di TestRail mi ha anche permesso di risparmiare una notevole quantità di tempo.
Ciò che apprezzo di più di TestRail è che offre al nostro team di controllo qualità un ambiente sicuro e ben organizzato per gestire piani di test, casi di test ed esecuzioni dei test. Apprezzo la semplicità con cui è possibile strutturare e implementare le suite di test, nonché riutilizzare i casi di test creati in precedenza. Le integrazioni con Jira e gli strumenti CI/CD hanno reso il nostro flusso di lavoro più coerente e più facile da monitorare. La possibilità di monitorare in tempo reale lo stato di avanzamento e la copertura dei test si è rivelata incredibilmente utile per la pianificazione degli sprint e la reportistica. Nel mio lavoro quotidiano come ingegnere QA, l’utilizzo di TestRail mi ha anche permesso di risparmiare una notevole quantità di tempo.
Ideale per: un team di controllo qualità composto da cinque o più persone che esegue cicli di test formali per ogni release, in cui un responsabile deve rispondere alla domanda «quale percentuale della Release 2.0 è stata eseguita e superata» direttamente da una dashboard, anziché da un foglio di calcolo.
Salta questo passaggio se: la tua suite conta meno di qualche centinaio di casi o i tuoi tester ricoprono anche il ruolo di sviluppatori. A quel livello, il costo per postazione e l’accesso separato ti garantiscono la reportistica che non consulterai mai.
Zephyr
Zephyr è il plugin di gestione dei test di SmartBear per Jira, progettato per gestire i casi di test direttamente dall’interfaccia di Jira. Supporta sia i test manuali che quelli automatizzati, con potenti funzionalità di reportistica e tracciabilità per i team agili e aziendali.
Caratteristiche principali di Zephyr
- Integrazione nativa con Jira: crea, collega ed esegui casi di test direttamente dagli problemi di Jira
- Librerie di test gerarchiche trasversali ai progetti per il riutilizzo e l’organizzazione dei casi di test su larga scala
- Oltre 70 report predefiniti che coprono la copertura dei test, lo stato di avanzamento dell'esecuzione e il monitoraggio dei difetti
- Supporto BDD con sintassi Gherkin per flussi di lavoro di sviluppo guidato dal comportamento (BDD)
- Integrazioni CI/CD con Jenkins, GitHub, Gitlab, Bitbucket e Bamboo
Limiti di Zephyr
- Licenza per utente Jira, non per tester
- Large repositories of test cases (thousands of cases) can be more difficult to navigate compared to independent tools like TestRail
- L’assistenza viene gestita tramite Atlassian Marketplace, il che aggiunge un ulteriore livello di supporto per i team abituati all’assistenza diretta del fornitore
Prezzi di Zephyr
- Essential: a partire da 5,99 $ al mese per utente (11-50 utenti)
- Standard: a partire da 6,81 $/utente/mese (11-50 utenti)
- Avanzato: a partire da 8,73 $/utente/mese (11-50 utenti)
Valutazioni e recensioni su Zephyr
- G2: 4,1/5 (oltre 80 recensioni)
- Capterra: Recensioni insufficienti
Cosa dicono gli utenti reali di Zephyr?
Ecco cosa dice un recensore su G2:
Questo è lo strumento ideale per importare casi di test direttamente da un foglio Excel. Grazie a questo strumento, il lavoro dei tester risulta meno impegnativo rispetto all’importazione dei casi di test in Jira. Inoltre, una delle migliori funzionalità di questo strumento è la possibilità di contrassegnare i casi di test come superati o falliti e di aggiungere allegati.
Questo è lo strumento ideale per importare casi di test direttamente da un foglio Excel. Grazie a questo strumento, il lavoro dei tester risulta più semplice rispetto all’importazione dei casi di test in Jira. Inoltre, una delle migliori funzionalità di questo strumento è la possibilità di contrassegnare i casi di test come superati o falliti e di aggiungere allegati.
Ideale per: team soggetti a normative o a frequenti audit (fintech, sanità) che hanno bisogno che ogni test sia ricondotto a un requisito Jira e che ogni difetto sia collegato al test che lo ha individuato, il tutto all’interno di un’unica istanza Atlassian.
Da evitare se: la tua istanza di Jira è di grandi dimensioni e il tuo team di controllo qualità è piccolo. Un Jira da 200 postazioni con 10 tester comporta il pagamento di 190 licenze Zephyr che nessuno utilizza; uno strumento autonomo con un prezzo per singolo tester costa meno.
Jira
Jira è la piattaforma di project management e di tracciamento dei ticket di Atlassian, ampiamente utilizzata dai team di ingegneri e di controllo qualità per gestire sprint, bug e flussi di lavoro di sviluppo. Sebbene non sia uno strumento dedicato alla gestione dei test, molti team lo utilizzano insieme a soluzioni come Zephyr Scale o Xray per gestire i casi di test all’interno della loro configurazione Jira esistente.
Funzionalità principali di Jira
- Bacheca Scrum e Kanban per la gestione di sprint, backlog e flussi di lavoro di test Agile
- Flussi di lavoro, tipi di problema e campi personalizzabili per adattarsi al modo in cui il tuo team effettua il monitoraggio del lavoro
- Roadmap avanzate per la pianificazione tra team e il monitoraggio delle dipendenze (Premium)
- Oltre 1.000 integrazioni con piattaforme, tra cui GitHub, Confluence, Slack e strumenti CI/CD
- Regole di automazione per trigger azioni in tutti i progetti in base agli aggiornamenti dei problemi o alle modifiche di stato
Limiti di Jira
- La gestione dei casi di test richiede un plugin del Marketplace (Zephyr Scale, Xray) con un costo aggiuntivo per utente oltre alla sottoscrizione a Jira
- Curva di apprendimento più ripida per gli utenti non tecnici, con costi di formazione iniziale che possono diventare significativi per i team più grandi
Prezzi di Jira
- Free
- Standard: 7,91 $/utente/mese
- Premium: 14,54 $/utente/mese
- Enterprise: prezzi personalizzati
Valutazioni e recensioni su Jira
- G2: 4,3/5 (oltre 7.900 recensioni)
- Capterra: 4,4/5 (oltre 15.400 recensioni)
Cosa dicono gli utenti reali di Jira?
Ecco cosa dice un recensore su G2:
Jira è uno dei miei programmi digitali preferiti per il monitoraggio e la visualizzazione dell’andamento di tutti i miei progetti di lavoro in collaborazione con tutti i membri del mio team, poiché offre le migliori funzionalità di monitoraggio virtuale della sua categoria, rendendo più facile il raggiungimento di tutti i miei obiettivi professionali.
Jira è uno dei miei programmi digitali preferiti per il monitoraggio e la visualizzazione dell'andamento di tutti i miei progetti di lavoro in collaborazione con tutti i membri del mio team, poiché offre le migliori funzionalità di monitoraggio virtuale della sua categoria, rendendo più facile il raggiungimento di tutti i miei obiettivi professionali.
Ideale per: team di ingegneri che stanno valutando se abbiano effettivamente bisogno di una gestione dedicata dei test. Eseguire inizialmente alcuni cicli di test utilizzando tipi di issue Jira personalizzati permette di capire se il volume di lavoro giustifica l’utilizzo di un plugin.
Salta questo passaggio se: sai già di aver bisogno di una gestione dei test. Passare direttamente a un plugin o a uno strumento autonomo ti evita la migrazione quando i tipi di problema personalizzati smettono di essere scalabili.
Errori comuni da evitare nella creazione dei casi di test
Evita questi errori nella scrittura dei casi di test che possono ridurne l’efficacia complessiva.
| Errore | Cosa fare invece |
|---|---|
| Scrivere i casi di test troppo tardi | Coinvolgi i tester nelle fasi di raccolta dei requisiti e di progettazione per individuare potenziali problemi prima che inizi la fase di codifica del codice |
| Non aggiornare i casi di test | Aggiorna il caso di test non appena la funzionalità riceve un nuovo aggiornamento, subisce una modifica nella funzionalità o viene modificata l'interfaccia utente |
| Nessuna postcondizione | Specifica come dovrebbe presentarsi il sistema al termine del test (utente di prova eliminato, carrello svuotato, sessione chiusa), in modo che il caso successivo parta da uno stato pulito |
| Solo dati relativi al percorso normale | Ogni campo di immissione dati deve contenere almeno un valore che il sistema dovrebbe rifiutare. Documenta come viene generato o recuperato il set di dati |
| Mancata definizione delle priorità dei casi di test | Assegna a ciascun caso di test una priorità in base all’impatto aziendale, alla frequenza di utilizzo e al rischio di fallimento. Questo ti aiuterà a concentrare il lavoro richiesto per i test e a prendere decisioni più oculate in merito al budget e ai metodi di test |
Come garantire che i casi di test rimangano utili nel tempo
Una suite di test rimane affidabile quando ogni caso è indipendente, si concentra sugli input che con maggiore probabilità causano errori e viene ritirata nel momento in cui smette di fornire un verdetto affidabile. Queste sei pratiche distinguono le suite che individuano i bug per anni da quelle che vengono ignorate già dopo il secondo sprint.
Scrivi test indipendenti e atomici
Un caso di test dovrebbe definire autonomamente il proprio stato e non avere alcuna dipendenza dall’esecuzione preventiva di un altro caso. Quando TC_CHECKOUT_003 presuppone che TC_CHECKOUT_002 abbia lasciato un elemento nel carrello, un singolo errore si trasforma in una cascata di cinque errori e si passa la mattinata a cercare di capire quale fosse quello reale. Se il titolo di un test contiene la parola “e”, suddividilo in due casi.
Eseguire i test ai limiti
Bugs si concentrano ai margini degli input accettati, non al centro. Se un campo password accetta da 8 a 128 caratteri, testa 7, 8, 128 e 129, non solo una comoda password di 12 caratteri. L’analisi dei valori limite è una tecnica formale prevista dallo standard di progettazione dei test ISO/IEC/IEEE 29119-4 proprio per questo motivo: individua gli errori “off-by-one” che gli input casuali non rilevano.
Utilizza il partizionamento per equivalenze per eliminare i casi ridondanti
Raggruppa gli input che il sistema dovrebbe trattare in modo identico, quindi testa un esempio rappresentativo per ciascun gruppo. Ogni formato di e-mail valido si comporta allo stesso modo in un modulo di accesso, quindi è sufficiente un solo indirizzo e-mail valido. Testare user@example.com, jane@company.com e bob@domain.org come tre casi distinti triplica il carico di manutenzione senza aumentare la copertura.
Separare i dati di test dai passaggi di test
Inserire in modo rigido “inserisci test@example.com” in un passaggio significa riscrivere il passaggio ogni volta che cambia l’ambiente di test. Mantieni i passaggi generici (“inserisci un’email registrata”) e conserva i valori effettivi in un campo o in un file di dati di test. Gli stessi passaggi verranno quindi eseguiti su staging, QA e pre-produzione senza modifiche, e sostituire un nuovo set di dati per un test negativo richiederà solo una riga di codice.
Monitoraggio dei test instabili e del tasso di difetti sfuggiti
Un test instabile fallisce in modo incostante senza che vi sia un vero bug nel prodotto, e ogni test instabile porta il team a ignorare i risultati negativi. Tieni traccia della frequenza con cui ogni caso oscilla tra superamento e fallimento su build identiche. Se un caso risulta instabile più di un paio di volte al mese, riscrivilo o rimuovilo. Abbina questo dato al tasso di sfuggita dei difetti (bug rilevati in produzione che un caso di test avrebbe dovuto individuare) per individuare dove la copertura è insufficiente, non solo dove è rumorosa.
Automatizza i test che esegui più spesso
I casi di regressione, di smoke test e funzionali ad alta frequenza sono i candidati ideali per l’automazione, poiché vengono eseguiti ad ogni build e cambiano raramente. Trasferiscili in script all’interno della tua pipeline CI/CD e utilizza strumenti di IA con localizzatori auto-riparanti laddove gli elementi dell’interfaccia utente cambiano spesso. Ciò consente ai tester umani di dedicarsi al lavoro esplorativo e a quei tipi di test del software che richiedono capacità di giudizio, come la verifica dell’usabilità e l’individuazione dei casi limite.
Come scrivere ed eseguire casi di test in ClickUp
La sezione sugli strumenti riportata sopra illustra il ruolo di ClickUp. Questa sezione mostra la configurazione effettiva, in linea con i passaggi descritti in precedenza nella guida.
Struttura la tua libreria di casi di test. Crea uno Spazio per il tuo prodotto, una Cartella per ogni area di funzionalità (ad es. Autenticazione, Pagamenti, Onboarding) e un Elenco per ogni ciclo di test o sprint. Ogni attività diventa un singolo caso di test. Utilizza i campi personalizzati di ClickUp per registrare elementi quali l'ID del caso di test, le precondizioni, i dati di test, il livello di priorità e l'ambiente.
Scrivi i passaggi di test direttamente nell'attività. Utilizza la descrizione dell'attività per documentare i passaggi di esecuzione sequenziali e i risultati attesi. Le liste di controllo sono utili per i flussi passo dopo passo in cui un tester deve spuntare ogni azione, mentre la descrizione contiene informazioni contestuali come le precondizioni e i dati di test.
Tieni traccia dell'esecuzione e dei risultati. Crea stati personalizzati che rispecchino il tuo flusso di lavoro di test: Non avviato → In corso → Superato → Fallito → Bloccato. Quando un test fallisce, convertilo in un'attività di bug o crea un'attività collegata assegnata allo sviluppatore, con priorità, dipendenze e una scadenza. Le integrazioni con GitHub e Gitlab ti consentono di collegare direttamente quel bug alla pull request che lo ha generato. Se la causa principale è un difetto nel codice, puoi assegnare quel ticket di bug all’agente ClickUp Codegen, che legge il ticket, le specifiche collegate e i commenti, scrive la correzione e apre una richiesta pull con l’stato riportato nel ticket.
Consiglio da esperto: I responsabili del controllo qualità possono ottenere una panoramica immediata di qualsiasi attività chiedendo a ClickUp Brain di riepilogare le attività relative ai bug aperti. In questo modo, dispongono di tutto il contesto necessario per le revisioni dei sprint senza dover setacciare le singole attività per ricostruire il quadro generale.
Esegui cicli di test con le diverse visualizzazioni. Utilizza la vista Bacheca, raggruppata per stato, per vedere a colpo d’occhio la distribuzione tra superati e falliti durante l’esecuzione di un test. La vista Tabella funziona come una tradizionale matrice di test quando devi esaminare i risultati di decine di casi. Filtra per assegnatario per bilanciare il carico di lavoro, oppure per priorità per concentrare innanzitutto uno smoke test sui percorsi critici.
Il modello di gestione dei test di ClickUp ti offre un modo centralizzato per gestire l'intero flusso di lavoro dei test, che abbraccia diverse funzionalità/funzioni, scenari di test e casi limite, tutto in un unico posto. Usalo per tenere traccia del feedback degli utenti, gestire i programmi di test, monitorare lo stato di avanzamento dei tuoi test e valutare i risultati di superamento o fallimento senza dover passare da uno strumento all'altro.
Gestisci in modo efficace i tuoi flussi di lavoro di test
Un caso di test è valido nel momento in cui due persone possono eseguirlo in modo indipendente e ottenere lo stesso risultato (superato o fallito). Tutto ciò che è contenuto in questa guida (un'azione per ogni passaggio, precondizioni esplicite, risultati attesi senza margine di interpretazione) è finalizzato a soddisfare questo unico standard. Se pianifichi già gli sprint in ClickUp, la configurazione descritta sopra ti consente di scrivere, eseguire e effettuare il monitoraggio dei casi di test insieme ai bug che essi evidenziano, senza dover aggiungere un altro strumento.
Domande frequenti sui casi di test
Quanti casi di test dovrebbe avere un requisito?
Un singolo requisito può richiedere un caso di test o dieci, a seconda del numero di scenari, casi limite e variazioni di input che comporta. L’idea è quella di coprire tutti i percorsi realistici, offrendo una copertura sufficiente senza ridondanze.
Qual è la differenza tra casi di test e script di test?
Un caso di test documenta cosa testare e quale risultato aspettarsi, ed è scritto per essere eseguito manualmente. Uno script di test, invece, è la versione automatizzata: codice che esegue gli stessi passaggi a livello di programmazione.
Quanto devono essere dettagliati i passaggi di test?
Suddividi il test in passaggi logici e sequenziali, facili da seguire anche senza conoscere il contesto precedente. Non raggruppare più azioni insieme né aggiungere complessità superflue.
Uno scenario di test indica cosa testare in una sola riga (“Verifica reimpostazione password”); un caso di test specifica come, con precondizioni, passaggi, dati di test e risultati attesi. Uno scenario produce in genere da 3 a 10 casi di test che coprono il percorso normale, gli input non validi e le condizioni al limite. Gli scenari vengono prima e guidano la pianificazione della copertura; i casi di test vengono dopo e guidano l’esecuzione.
Un caso di test positivo utilizza input validi e prevede un esito positivo: un indirizzo email e una password corretti consentono all’utente di effettuare l’accesso. Un caso di test negativo utilizza input non validi o inattesi e prevede che il sistema fallisca in modo corretto: una password errata mostra il messaggio “Password non valida” senza creare una sessione. Le suite di test mature presentano un rapporto tra casi positivi e negativi compreso approssimativamente tra 1:3 e 1:5, poiché la maggior parte dei bug di produzione si trova nei percorsi di errore, non in quelli di successo.
Un piano di test definisce l’ambito, l’approccio, le risorse e la tempistica dell’intero lavoro richiesto per i test. Una suite di test è un insieme di casi di test raggruppati per un’unica esecuzione, come ad esempio la «suite di regressione per la versione 2.1». Un caso di test è l’unità fondamentale di entrambi: una verifica documentata con un esito di superamento o fallimento. Il piano definisce la strategia, la suite definisce l’ambito, il caso definisce il verdetto.