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, che 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 possono essere riprodotte e il controllo qualità diventa un collo di bottiglia invece che una rete di sicurezza.
Scrivere un buon caso di test non dipende tanto dall’abilità di testare, quanto piuttosto dalla progettazione della verifica. Nel settore dei servizi finanziari questo processo è noto come “maker-checker”. Nel comando nucleare viene chiamato “regola delle due persone”. Il principio è lo stesso: un lavoro critico non dovrebbe mai basarsi su un’unica azione non verificata. Un caso di test ben scritto incorpora 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 essere dotato di un ID univoco, di precondizioni e di risultati attesi ben definiti, in modo da poter verificare l’esito. 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 in modo programmatico). 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 proceda con ciascun passaggio
- Inserisci dati con valori di campione per testare diversi esiti 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 | Eseguito 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 operatori 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 mantenuti |
| 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
Individui le regressioni prima 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 dopo un anno 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 correggere il 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 possiede 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 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 specifici, 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 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à che trasforma 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 di un buon caso di test
Un caso di test utile non si limita a descrivere cosa testare. Coglie 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.
I componenti di un caso di test sono:
- Identificatore univoco
- Scopo o descrizione
- Prerequisiti
- Passaggi di esecuzione
- Risultati attesi
- Risultati effettivi a titolo 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 in modo che 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.
Prerequisiti: i prerequisiti descrivono lo stato del sistema richiesto prima dell’esecuzione del caso di test. Senza di essi, i tester potrebbero eseguire lo stesso test in condizioni diverse e ottenere risultati incoerenti.
Esempi:
- L'account dell'utente deve già esistere 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 Accedi
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 riportano 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 sapevi? Solo il 2,1% dei team descrive le proprie pratiche di test dell’IA come ottimizzate, mentre oltre l’85% si trova ancora in 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 scrittura di un caso di test prevede sette passaggi: analizzare i requisiti, creare un elenco degli scenari, creare un piano per la struttura, scrivere i passaggi con i risultati attesi, creare un allegato con il contesto, farli revisionare, quindi eseguirli e registrarli.
Passaggio 1: Analizza i requisiti
Prima di scrivere il caso di test, cerca di capire 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, ovvero: un utente può riottenere l'accesso al proprio account se dimentica la password?
- Quali azioni può eseguire 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?
- Esistono delle restrizioni, ovvero il link scade dopo un determinato periodo di tempo o diventa non valido dopo un solo utilizzo?
- Esistono convalide o regole, ovvero la nuova password deve soddisfare requisiti specifici in termini di formato o lunghezza?
- C’è qualche funzione poco chiara o non 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 possa 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 inviata un’email che non esiste nel sistema
- Link scaduto: Verifica che il sistema imponga il blocco dell'accesso quando si fa clic sul link di reimpostazione dopo la sua scadenza
- Link riutilizzato: Verifica che un link di ripristino già utilizzato non possa essere riutilizzato
- Nuova password non valida: verifica che le password che non soddisfano i requisiti di formato vengano rifiutate
- Richieste multiple di ripristino: 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 ti consenta di documentare i casi 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 ricominciare da zero ogni volta.
Pianifica l'esecuzione dei test chiarendo questi elementi:
Chi effettuerà il test?
Quali sono i requisiti o le qualifiche necessarie per la persona che esegue questo test? A seconda della complessità del test e dell'intervento umano richiesto, assegna i ruoli:
- Tester QA: test funzionali e di regressione, come la verifica dei flussi di accesso, la convalida dei moduli o i processi di checkout
- Team di sicurezza: Test relativi a vulnerabilità legate all’autenticazione, al controllo degli accessi o all’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 rendi ciascuna di esse 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 funzionante
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 rispetti esattamente il limite 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 superamento o un fallimento del test.
Proseguendo con il nostro flusso di reimpostazione della password, ecco come potrebbero presentarsi 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'email è valida 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 ripristino 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). Descrivi cosa succede quando l’utente inserisce un indirizzo email non valido o la password non soddisfa i criteri prestabiliti.
Bonus: Ecco come puoi effettuare l’automazione della documentazione utilizzando l’IA per tutti i tuoi casi di test.
Passaggio 5: Includi 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 commentati 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 facilitare la diagnosi dei problemi del backend quando un test fallisce
- Documenti sui 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 utente
- Prepara la documentazione relativa alla versione specifica del software, all’hardware richiesto, al sistema operativo e a eventuali autorizzazioni di sicurezza necessarie
- Per il test 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 scritto con un collega o con un responsabile senior del controllo qualità prima di eseguirlo. Durante la revisione, verifica che:
- Il caso di test è completo 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 caratteristica come “funziona correttamente”
- I dati di test e le precondizioni sono completi e accurati
- Eventuali ipotesi formulate durante la stesura sono documentate in modo esplicito
Passaggio 7: Esegui i test e registra i risultati
Esegui il test e registra il risultato effettivo a fronte di ciascun risultato atteso. Contrassegna un test come superato o fallito ad 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 sia chiaramente da considerarsi superato o fallito, annotalo nel campo dei commenti per un’ulteriore revisione.
Per saperne di più: Come utilizzare l'IA per il controllo 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 stai 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 estende su più pagine: carrello → spedizione → pagamento → conferma. La sfida principale in questo caso è rappresentata dalla dipendenza dagli stati: 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 del test: 09/03/2026
ID del caso di test: TC_CHECKOUT_003
Descrizione: Verifica che un utente che ha effettuato l'accesso possa completare un acquisto utilizzando una carta di credito salvata e la spedizione standard.
Prerequisiti:
- Esiste un account utente con 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 delle pagine di spedizione con l’indirizzo salvato già preselezionato | Come previsto | Supera |
| Seleziona “Spedizione standard” e clicca su Continua | La pagina di pagamento si carica 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 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 |
Riassunto 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 l’interfaccia tra i sistemi, non l’esperienza utente.
Tester: Sarah S.
Data del test: 09/05/2026
ID del 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 dell'API è attivo e accessibile
- È stato generato un token di autenticazione con autorizzazioni di amministratore, che risulta valido
- Nel database non esiste alcun utente con l'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 il codice 201 "Creato" con un corpo JSON contenente l'ID dell'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 il codice di errore 409 (Conflitto) con il messaggio: “Esiste già un utente con questo indirizzo email” | Risposta 200 OK; utente duplicato creato | Errore |
| Invia una richiesta POST con il campo “email” mancante | La risposta restituisce un codice di errore 400 (Bad Request) 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 generato 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 è 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 del test: 09/08/2026
ID del caso di test: TC_RBAC_002
Descrizione: Verifica che un utente con il ruolo "Visualizzatore" non possa creare, modificare o eliminare progetti.
Prerequisiti:
- Esistono due account: uno con il ruolo “Amministratore” e uno con il ruolo “Visualizzatore”
- 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'azione; 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 l'azione è bloccata 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 i "Visualizzatori", ma le autorizzazioni di modifica non vengono applicate a livello di campo. Un "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 gestire i 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 tu abbia bisogno di un'esecuzione integrata o semplicemente di un 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 tra Spazi, Cartelle ed Elenchi con campi personalizzati per tipo di test, priorità e ambiente
- Oltre 15 viste di ClickUp (bacheca, elenco, tabella) per il monitoraggio dell’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 nativo per l'esecuzione dei test
- 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à, sequenze, 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à, sequenze, 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 viste in modo che si adattino 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 gli sviluppatori con un solo clic, con la PR, 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 una persona ad aggiornare lo stato.
TestRail
TestRail è una piattaforma dedicata alla gestione dei test, pensata 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 alimentano 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 e cronologia delle esecuzioni
- Integrazioni con Jira, GitHub, Jenkins, Azure DevOps e oltre 20 altri strumenti DevOps
- API REST per automatizzare le attività e effettuare la sincronizzazione dei dati di test con sistemi esterni
Limiti di TestRail
- Non sono disponibili funzionalità native per la gestione dei requisiti o del 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 dei test raggiungono le migliaia
Prezzi di TestRail
- Professional: 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 fatto 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 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.
Ideale per: un team di controllo qualità composto da cinque o più membri 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” da una dashboard, non 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.
Funzionalità 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 riutilizzare e organizzare i 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
- 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 autonomous tools like TestRail
- L'assistenza viene gestita tramite Atlassian Marketplace, il che aggiunge un ulteriore livello per i team abituati a ricevere supporto direttamente dal fornitore
Prezzi di Zephyr
- Essential: a partire da 5,99 $/utente/mese (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 di G2:
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. Un’altra funzionalità eccellente 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. Una funzionalità eccellente 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, settore sanitario) che necessitano 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 prezzo per singolo tester costa meno.
Jira
Jira è la piattaforma di project management e di tracciamento dei problemi 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
- Bacheche Scrum e Kanban per la gestione di sprint, backlog e flussi di lavoro di test Agile
- Flussi di lavoro, tipi di ticket 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 di terze parti, tra cui GitHub, Confluence, Slack e strumenti CI/CD
- Regole di automazione per trigger azioni in tutti i progetti in base agli aggiornamenti delle segnalazioni 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 onboarding 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 di 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 lavorativi 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 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 dell'inizio della codifica |
| I casi di test non vengono aggiornati | Aggiorna il caso di test non appena la funzionalità/funzione riceve un nuovo aggiornamento, una modifica alle funzionalità o un cambiamento nell'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 allo scenario ideale | Ogni campo di immissione dati deve contenere almeno un valore che il sistema dovrebbe rifiutare. Documenta come viene generato o estratto il set di dati |
| Mancata definizione delle priorità dei casi di test | Assegna a ciascun caso di test una priorità in base all’impatto sul business, alla frequenza di utilizzo e al rischio di fallimento. Questo ti aiuta a concentrare il lavoro richiesto per i test e a prendere decisioni più oculate in merito al budget e ai metodi di test |
Come mantenere i casi di test 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 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 errore si trasforma in una cascata di cinque errori e ti ritrovi a passare la mattinata a cercare di capire quale fosse quello reale. Se il titolo di un test contiene la parola “e”, suddividilo in due casi.
Esegui 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 la partizionatura per equivalenza 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 email valido si comporta allo stesso modo in un modulo di accesso, quindi è sufficiente un solo indirizzo email 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.
Separa i dati di test dai passaggi di test
Inserire in modo rigido “inserisci test@example.com” in un passaggio significa dover 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 sfuggimento dei difetti
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 alterna esito positivo e negativo 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, smoke 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 assistiti dall’IA con localizzatori auto-riparanti laddove gli elementi dell’interfaccia utente cambiano spesso. Ciò consente ai tester umani di dedicarsi al lavoro esplorativo e ai tipi di test software che richiedono capacità di giudizio, come l’usabilità e l’individuazione dei casi limite.
Come scrivere ed eseguire casi di test in ClickUp
La sezione "Strumenti" sopra illustra il ruolo di ClickUp. Questa sezione mostra la configurazione effettiva, mappata sui passaggi descritti in precedenza nella guida.
Struttura la tua libreria di casi di test. Crea uno Spazio per il tuo prodotto, una Cartella per ciascuna 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 ideali per i flussi passo dopo passo in cui un tester deve spuntare ogni azione, mentre la descrizione contiene informazioni di contesto 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 richiesta pull che lo ha introdotto. Se la causa principale è un difetto nel codice, puoi assegnare quella attività relativa al bug a ClickUp Codegen Agent, che legge la descrizione dell’attività, le specifiche collegate e i commenti, scrive una proposta di correzione e apre una richiesta pull per la revisione, con lo stato riportato nell’attività.
Suggerimento 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 degli 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 di test, che abbraccia diverse aree funzionali, 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 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 ottenendo 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) risponde a 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 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 l’esecuzione manuale. 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à non necessarie.
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 si aspetta un esito positivo: un indirizzo e-mail e una password corretti consentono all’utente di effettuare l’accesso. Un caso di test negativo utilizza input non validi o inattesi e si aspetta che il sistema gestisca l’errore 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 che varia all’incirca da 1:3 a 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 una singola esecuzione, come ad esempio la “suite di regressione per la versione 2.1”. Un caso di test è l’unità fondamentale all’interno 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.