Risposta.

La redazione dei test case è uno dei fondamenti del testing manuale e un passaggio chiave per la verifica della funzionalità dell'applicazione.

Storia della questione: Per molto tempo, i test case sono stati il metodo centrale di controllo qualità: permettono di strutturare il controllo dei requisiti e garantiscono la ripetibilità del testing indipendentemente dal cambio dei tester.

Problema: La principale difficoltà è il bilanciamento tra eccessiva dettagliatura e insufficiente elaborazione. Test case eccessivamente dettagliati rendono il testing routinario e lento, mentre quelli troppo sintetici possono trascurare scenari importanti. I problemi comunemente riscontrati includono:

Insufficiente collegamento con i requisiti.
Omissione di casi limite.
Duplicazione di scenari.
Obsolescenza a causa di cambiamenti nel prodotto.

Soluzione: Per un test case efficace è necessario:

Creare un collegamento tra ogni test e i requisiti (matrice di tracciabilità).
Utilizzare tecniche di design dei test (partizione equivalente, analisi dei casi limite).
Effettuare audit regolari e aggiornamenti dei test case.
Coinvolgere il team di sviluppo e gli analisti per chiarire aspetti complessi.

Caratteristiche chiave:

Strutturazione secondo il principio “un test - un risultato atteso”.
Aggiornamenti in caso di variazione dei requisiti.
Copertura di tutti i percorsi, inclusi i casi negativi.

Domande trabocchetto.

I test case devono sempre essere scritti prima dello sviluppo?

No. Anche se è desiderabile scriverli prima dell’inizio dell’implementazione (shift-left), nella pratica spesso i test case vengono rivisitati man mano che arriva nuova informazione o dopo il setting dell'ambiente di test.

Un test case deve verificare solo un singolo scenario?

Sì, il principio classico “un test - un risultato” facilita l'analisi dei bug e comprende cosa è stato testato. Possibili eccezioni possono essere fatte per scenari end-to-end, ma è comunque importante definire chiaramente i risultati attesi.

Si può fidare completamente dei test case generati automaticamente dai requisiti?

No. Tali test case sono spesso superficiali e possono trascurare logiche aziendali importanti, valori limite o combinazioni di azioni, quindi è necessaria un'analisi manuale.

Errori tipici e anti-patterns

Copiatura di vecchi test case senza adattamento ai nuovi requisiti.
Omissione di scenari negativi.
Uso di formulazioni vaghe (ad esempio, “il sistema funziona correttamente”).

Esempi dalla vita reale

Caso negativo

Il team ha utilizzato una documentazione di test vecchia senza revisione e ha continuato a usare test case non adattati alla funzionalità cambiata.

Vantaggi:

Risparmio di tempo nella creazione di nuovi documenti.

Svantaggi:

Regole aziendali nuove trascurate, bug scoperti solo dopo il rilascio in produzione.

Caso positivo

Il tester ha revisionato i test case, ha discusso i punti difficili con gli analisti, ha identificato quelli obsoleti e ha condotto una revisione con il nuovo team.