Cos'è un caso di test? Come scriverne uno che qualcun altro possa eseguire

Un caso di test è una singola verifica, scritta perché chi non l’ha redatta possa eseguirla e ottenere la stessa risposta. Nomina uno stato di partenza, i passi da compiere e ciò che dovrebbe accadere. Se due persone lo eseguono e non sono d’accordo sul fatto che sia passato, non è finito.

È tutta qui l’idea, ed è la stessa idea di una segnalazione di bug presa dall’altro lato. Una segnalazione dice “ecco come far andare storto qualcosa”. Un caso di test dice “ecco come verificare che vada bene”.

Che cosa contiene

Sei parti, e solo tre sono quelle interessanti.

• Un identificatore per poterlo citare in un report di build o in una conversazione
• Un titolo che dica che cosa si sta verificando, non su che cosa si sta cliccando
• Precondizioni: lo stato in cui deve trovarsi il mondo perché il passo uno abbia senso
• Passi, numerati, ognuno un’azione
• Risultato atteso, abbastanza specifico da poter essere sbagliato
• Risultato effettivo, compilato quando viene eseguito

I tre che decidono se funziona sono le precondizioni, il risultato atteso e il titolo. I passi sono facili. Sapere quale stato il test dà per scontato, e che cosa significa “corretto” con la precisione necessaria per poterne discutere, è il lavoro.

Scrivere il titolo

Un titolo si legge dentro un elenco di duecento, quindi dovrebbe dire che cosa viene verificato.

Debole

Testare la pagina di accesso

Meglio

L'accesso viene rifiutato, con un messaggio, quando la password è sbagliata

Il secondo ti dice che cosa copre, che cosa significherebbe un fallimento e se duplica quello sotto. Il primo non ti dice nulla, e fra sei mesi nessuno saprà se copre il messaggio di errore oppure no.

Scrivere i passi

Numerali e metti esattamente un’azione in ciascuno. Il test non è il posto in cui essere risparmiosi.

Titolo:        L'accesso viene rifiutato, con un messaggio, quando la password è sbagliata
Precondizioni: Esiste un account confermato per ada@example.com
Passi:
  1. Aprire /login
  2. Inserire ada@example.com nel campo email
  3. Inserire wrongpassword nel campo password
  4. Fare clic su Accedi
Atteso:        La pagina resta su /login, mostra "Email o password non corretti",
               e il campo password viene svuotato

Nota che cosa il risultato atteso non dice: “compare un errore”. Tre implementazioni diverse soddisfano quella frase e due di esse sono sbagliate. Nomina anche ciò che non sarebbe dovuto accadere, cioè nessuna navigazione, perché un test che controlla solo il messaggio passa anche su una pagina che mostra il messaggio e intanto fa entrare l’utente.

Che cosa rovina un caso di test

Dipende dal test precedente. Un caso che passa solo se prima è stato eseguito quello prima non può essere eseguito da solo, non può essere riordinato e crolla in blocco quando qualcosa si rompe presto. Ogni caso predispone le proprie precondizioni.

Verifica sei cose. Quando fallisce impari che una di sei cose è sbagliata. Dividilo.

Descrive l’interfaccia invece del comportamento. “Fare clic sul pulsante blu in alto a destra” si rompe quando il pulsante si sposta; “Inviare il modulo” no.

Il suo risultato atteso è un’alzata di spalle. “Funziona correttamente”, “come da progetto”, “nessun errore” - tutto questo significa che decide chi lo esegue, che è proprio la cosa che un caso di test esiste per evitare.

Testa ciò che non può fallire. Un caso che verifica che un’intestazione statica riporti le parole giuste costa tempo a ogni esecuzione, per sempre. Spendi lo sforzo dove vive il comportamento.

Casi manuali e casi automatizzati

La stessa disciplina, un’economia diversa. Un caso automatizzato gira a ogni build e deve essere preciso, altrimenti sarà instabile; un caso manuale lo esegue una persona che può usare il giudizio, che è insieme la sua forza e il motivo per cui due persone ricavano due risposte da un caso vago.

Scrivi casi manuali per ciò che richiede giudizio - questo layout sembra sbagliato, questo messaggio ha senso - e automatizza ciò che ha un ingresso noto e una risposta nota. E tieni quelli manuali più corti di quanto pensi: un caso da quindici passi viene saltato a metà da chiunque lo esegua per la nona volta.

Quando uno fallisce

Un caso di test fallito è l’inizio di una segnalazione di bug, e parte avanti rispetto alla maggior parte: i passi sono già scritti, il risultato atteso è già enunciato, ed entrambi sono in un linguaggio su cui qualcuno può agire.

Quello che non porta con sé è il contesto della macchina su cui è fallito - il browser, la console, le richieste dietro la pagina. È la distanza fra “il caso di test 47 è fallito” e una segnalazione con cui uno sviluppatore può lavorare.

Allega l’identificatore del caso alla segnalazione e i due restano collegati: chi lo risolve può eseguire la stessa verifica, e chi eseguirà la verifica alla release successiva vedrà che una volta è fallita. La guida alla segnalazione di bug copre il resto di ciò che serve a quella segnalazione.

La versione breve

Una verifica per caso. Precondizioni che si predispone da solo. Passi che qualcun altro può seguire. Un risultato atteso abbastanza specifico perché due persone non possano essere in disaccordo sul fatto che sia accaduto. Tutto il resto è formattazione.