Definizione di scenari di test e priorità

Determina cosa testare, definisci gli scenari di test e dai la priorità.

Ramona Schwering

Nel post precedente, hai appreso le strategie di test, il numero di test necessari per testare un'applicazione e come trovare la soluzione migliore per ottenere la massima affidabilità dei risultati tenendo conto delle tue risorse. Tuttavia, questo ci dà solo un'idea di quanto testare. Devi ancora determinare esattamente cosa testare. I seguenti tre criteri possono essere utili per capire cosa aspettarsi da un test e per capire quale tipo di test e quale livello di dettaglio potrebbero essere più adatti:

1. Prenditi cura del tuo percorso ideale. Si tratta della storia utente più generica o principale della tua applicazione, in cui l'utente noterà molto rapidamente un errore.
2. Scegli con attenzione il livello di dettaglio. Fornisci maggiori dettagli se il tuo caso d'uso è vulnerabile o se un errore potrebbe causare danni ingenti.
3. Dai la priorità ai test di livello inferiore, come i test di unità e di integrazione, rispetto ai test end-to-end di livello superiore, se possibile.

Il resto di questo articolo illustra questi criteri e come vengono applicati durante la definizione dei casi di test.

Che cos'è un test case?

Nello sviluppo software, un test case è una sequenza di azioni o circostanze concepite per confermare l'efficacia di un programma o di un'applicazione software. Lo scopo di un test case è garantire che il software funzioni come previsto e che tutte le sue funzionalità e funzioni funzionino correttamente. In genere, sono gli sviluppatori o i tester di software a creare questi scenari di test per garantire che il software soddisfi i requisiti e le specifiche specificati.

Quando viene eseguito un caso di test, il software esegue una serie di controlli per assicurarsi di produrre i risultati desiderati. Nel farlo, un test esegue le seguenti attività:

• Verifica. La procedura di controllo accurato del software per assicurarsi che funzioni senza errori. È fondamentale determinare se il prodotto creato soddisfa tutti i requisiti non funzionali necessari e raggiunge correttamente lo scopo previsto. Risponde alla domanda: "Stiamo creando il prodotto giusto?"
• Convalida. La procedura per garantire che il prodotto software soddisfi gli standard o i requisiti di alto livello necessari. Consiste nel verificare se il prodotto effettivo è in linea con quello previsto. In sostanza, rispondiamo alla domanda: "Stiamo creando il prodotto giusto per le esigenze dell'utente?"

Supponiamo che il programma non generi il risultato previsto. In questo caso, lo scenario di test sarà il messaggero, quindi verrà segnalato un risultato negativo e lo sviluppatore o il tester dovrà esaminare il problema e trovare una soluzione. Considera i controlli e le azioni come percorsi seguiti dal computer, indipendentemente dal tipo di test. I gruppi di dati di input o condizioni utilizzati per il controllo sono chiamati "classi di equivalenza". Dovrebbero ottenere comportamenti o risultati simili dal sistema in test. I percorsi specifici eseguiti all'interno di un test possono variare, ma devono corrispondere alle attività e alle asserzioni eseguite nel test.

Percorsi di test: tipi di scenari di test tipici

Nello sviluppo software, un caso di test è uno scenario di esecuzione del codice da cui è previsto e testato un determinato comportamento. In genere, esistono tre scenari da cui formare i casi di test.

Il primo è il più noto e probabilmente lo stai già utilizzando. Si tratta del percorso ideale, noto anche come "happy day scenario" o "golden path". Definisce il caso d'uso più comune della tua funzionalità, applicazione o modifica, ovvero il modo in cui dovrebbe funzionare per il cliente.

Il secondo percorso di test più importante da coprire negli scenari di test viene spesso omesso perché spiacevole, come potrebbe suggerire il nome. È il "percorso spaventoso" o, in altre parole, il test negativo. Questo percorso ha come target gli scenari che causano un comportamento anomalo del codice o l'ingresso in uno stato di errore. Il test di questi scenari è particolarmente importante se hai casi d'uso altamente vulnerabili che comportano un rischio elevato per gli stakeholder o gli utenti.

Esistono altri percorsi che potresti conoscere e prendere in considerazione, ma in genere sono meno utilizzati. che abbiamo riassunto nella seguente tabella:

Esistono diversi metodi per classificare questi percorsi. Ecco due approcci comuni:

• Suddivisione in base all'equivalenza. Un metodo di test che classifica gli scenari di test in gruppi o partizioni e, di conseguenza, aiuta a creare classi di equivalenza. Questo approccio si basa sull'idea che se uno scenario di test in una partizione scopre un difetto, è probabile che altri scenari di test nella stessa partizione rivelino difetti simili. Poiché tutti gli input all'interno di una classe di equivalenza specifica dovrebbero avere un comportamento identico, puoi ridurre il numero di casi di test. Scopri di più sulla suddivisione in parti equivalenti.
• Analisi limite. Un metodo di test, noto anche come analisi dei valori limite, che esamina i limiti o gli estremi dei valori di input per trovare eventuali problemi o errori potenziali che potrebbero verificarsi ai limiti delle funzionalità o dei vincoli del sistema.

Best practice: scrittura dei casi di test

Uno scenario di test classico scritto da un tester conterrà dati specifici per aiutarti a comprendere i contenuti del test che vuoi eseguire ed, ovviamente, a eseguire il test. Un tester tipico documenta le attività di test in una tabella. In questa fase possiamo utilizzare due pattern che ci aiutano a strutturare i casi di test e, in un secondo momento, anche i test stessi:

• Schema Organizza, agisci, asserisci. Il pattern di test "organizza, esegui, verifica" (noto anche come "AAA" o "Triple A") è un modo per organizzare i test in tre passaggi distinti: organizzare il test, eseguirlo e, infine, trarre conclusioni.
• Modello Se, quando, allora. Questo pattern è simile al pattern AAA, ma ha alcune radici nello sviluppo guidato dal comportamento.

In articoli futuri approfondiremo questi pattern, non appena avremo trattato la struttura di un test. Se vuoi approfondire questi pattern in questa fase, consulta questi due articoli: Arrange-Act-Assert: un pattern per scrivere test efficaci e Given-When-Then.

In base a quanto appreso in questo articolo, la tabella seguente riassume un esempio classico:

Nei test automatici, non è necessario documentare tutti questi casi di test nel modo in cui deve fare un tester, anche se è senza dubbio utile farlo. Se fai attenzione, puoi trovare tutte queste informazioni nel test. Trasformiamo questo caso di test classico in un test automatico.