I nuovi tester spesso sentono questi due termini usati come se significassero la stessa cosa. Non lo fanno. La differenza tra un caso di test e uno scenario di test riguarda principalmente il livello di dettaglio e comprenderlo ti aiuta a decidere quanto scrivere prima di iniziare il test.

Questa guida spiega ciascuno di essi, quindi funziona attraverso un’unica funzionalità di reimpostazione della password, dai requisiti agli scenari fino ai casi di test completi. La funzione e le sue regole sono un esempio inventato. Anche la terminologia varia leggermente tra team e strumenti, quindi concorda cosa significano queste parole nel tuo team.

La risposta breve

Uno scenario di test descrive una situazione da verificare, ad esempio “verificare che un utente possa reimpostare una password dimenticata”. Di solito è una riga e lascia i dettagli al tester.

Un caso di test spiega esattamente come verificare una condizione all’interno di quella situazione: precondizioni, passaggi, dati di test e risultato atteso. Due tester che lo seguono dovrebbero raggiungere lo stesso verdetto.

Pensa a pianificare un viaggio. Lo scenario è “viaggio da Pune a Delhi”. Il test case è l’itinerario completo, con il numero del volo, l’orario di partenza e cosa fare in ogni tappa.

Caso di test e scenario di test fianco a fianco

Cos’è uno scenario di prova?

Uno scenario di test è una breve descrizione di qualcosa che un utente potrebbe fare o di una situazione che il sistema deve gestire. Si concentra su ciò che conta dall’esterno e di solito deriva direttamente da un requisito o dalla storia dell’utente.

Gli scenari sono preziosi perché sono veloci. Puoi elencarne trenta nel tempo necessario per scrivere tre casi dettagliati, il che li rende un ottimo modo per rivedere la copertura con un product Owner: “abbiamo pensato a tutto?” Un lettore non tecnico può seguire un elenco di scenari senza problemi.

Cos’è un caso di prova?

Un caso di test è un insieme di condizioni e passaggi specifici, utilizzati per determinare se una cosa funziona. Un tipico caso di test contiene:

• Un ID univoco e un titolo chiaro
• Precondizioni, ovvero ciò che deve essere vero prima di iniziare
• passi numerati
• dati di test specifici
• Un risultato atteso
• Il risultato effettivo e lo stato, compilati durante l’esecuzione

I casi di test brillano quando la coerenza è importante. Un nuovo membro del team può eseguirli, i risultati possono essere confrontati tra le versioni e si ha una registrazione di ciò che è stato verificato. Approfondiremo la nostra guida su come scrivere casi di test.

Una caratteristica, dall’inizio alla fine

Passaggio 1: il requisito

Gli utenti che dimenticano la password possono richiedere un collegamento di reimpostazione tramite e-mail. Il collegamento funziona una volta e scade dopo 30 minuti. Una nuova password deve contenere almeno 8 caratteri.

Passaggio 2: gli scenari di test

Guarda TS-02. Il requisito non dice mai cosa dovrebbe succedere con un’e-mail sconosciuta e la scrittura dello scenario ha messo in luce questa lacuna. La pagina dovrebbe rivelare che l’indirizzo non è registrato? Per motivi di sicurezza, di solito non dovrebbe, poiché ciò consente agli aggressori di scoprire account validi. Trovare queste domande in anticipo è uno dei maggiori vantaggi della scrittura di scenari.

Passaggio 3: i casi di test

Ora espandiamo solo TS-05 nei casi di test. Uno scenario diventa diversi:

Questi valori non erano casuali. TC-051 e TC-052 si trovano su entrambi i lati del limite, utilizzando l’analisi dei valori limite, e gli altri provengono dal partizionamento di equivalenza.

Un modello di caso di prova

Ecco il TC-052 scritto per intero. Copia questo layout se il tuo team non ha ancora uno standard:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Si noti che il risultato previsto controlla più del messaggio di errore. Conferma inoltre che la vecchia password funziona ancora e che il collegamento rimane utilizzabile. I casi di test deboli spesso si fermano a ciò che è visibile sullo schermo.

Dove si inseriscono nel quadro più ampio

Tradizionalmente, scenari e casi vengono scritti durante la fase di progettazione del test del ciclo di vita del test del software.

Quando utilizzarli ciascuno

Gli scenari sono spesso sufficienti quando:

• Il team è piccolo, esperto e conosce bene il prodotto.
• Il tempo è poco o i requisiti cambiano frequentemente.
• La funzionalità è a basso rischio.
• Desideri rivedere rapidamente la copertura con le parti interessate.
• Stai guidando test esplorativi.

Casi di test dettagliati valgono lo sforzo quando:

• Un fallimento sarebbe costoso, come nel caso dei pagamenti, della sicurezza o dei dati sanitari.
• Le autorità di regolamentazione o i revisori hanno bisogno di prove di ciò che è stato testato.
• I test devono essere eseguiti da tester nuovi o esternalizzati.
• I risultati devono essere ripetuti esattamente, come in una suite di regressione.
• I passaggi diventeranno test automatizzati.

Le squadre più mature li usano entrambi. Elencano scenari per tutto e scrivono casi completi solo per i rischi più elevati. Non è necessario documentare ogni passaggio di una pagina delle impostazioni a basso rischio allo stesso modo di un bonifico bancario.

Scenari, casi e automazione

Un caso di test ben scritto si associa quasi direttamente a un test automatizzato. Le precondizioni diventano impostazioni, i passaggi diventano azioni e il risultato atteso diventa un’asserzione. I framework di sviluppo basati sul comportamento usano persino la parola “Scenario” per le loro specifiche eseguibili:

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

In modo confuso, quello che BDD chiama scenario è molto più vicino a un caso di test, perché contiene dati e risultati specifici. Questo è un buon promemoria per concordare i termini. Per automatizzare questi controlli, consulta il nostro tutorial sul drammaturgo o il tutorial su pytest.

Cosa li rende buoni

Errori comuni

• Scrivere solo percorsi felici. La maggior parte dei bug si trova nelle condizioni di errore, quindi includi ciò che dovrebbe fallire.
• Utilizzo di risultati attesi vaghi. “Dovrebbe funzionare correttamente” consente a qualsiasi tester di decidere qualsiasi cosa.
• Documentare tutto per intero. Migliaia di casi che nessuno sostiene sono peggio di un piccolo insieme utile.
• Saltare gli scenari. Passare direttamente ai casi può lasciare intere aree dimenticate.
• Lasciare che le custodie diventino obsolete. Quando il prodotto cambia, le vecchie custodie ingannano le persone. Rivederli regolarmente.
• Legare i passaggi ai dettagli fragili. “Fai clic sul pulsante blu in alto” si interrompe con qualsiasi riprogettazione.

Considerazioni finali

Gli scenari ti danno ampiezza e i casi di test ti danno profondità. Inizia con gli scenari per la tua prossima funzionalità ed esaminali con uno sviluppatore e un proprietario del prodotto. Quindi espandi solo quelli rischiosi in casi completi. Troverai le lacune prima e trascorrerai il tuo tempo a scrivere dove conta.

Domande frequenti

Continua a imparare