Stabilisci cosa testare, definisci gli scenari di test e stabilisci la priorità.
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 acquisire la massima fiducia nei risultati, tenendo a mente le tue risorse. Tuttavia, questo ci dà solo un'idea di quanto testare. Devi comunque stabilire esattamente cosa testare. I tre criteri seguenti possono essere utili per capire cosa aspettarsi in un test e per individuare il tipo di test e il livello di dettaglio più adatti:
- Prenditi cura del tuo percorso felice. Questa è la storia utente più generica o principale della tua applicazione, in cui l'utente noterà un errore molto rapidamente.
- Stabilisci con attenzione il livello di dettaglio. Fornisci maggiori dettagli se il tuo caso d'uso è vulnerabile o dove un errore potrebbe causare danni gravi.
- Dai la priorità ai test di livello inferiore, come i test delle unità e di integrazione, rispetto ai test end-to-end di livello superiore quando possibile.
Nella parte restante di questo articolo vengono esplorati questi criteri e la loro applicazione durante la definizione degli scenari di test.
Che cos'è uno scenario di test?
Nello sviluppo di software, uno scenario di test è una sequenza di azioni o circostanze studiate per confermare l'efficacia di un programma software o di un'applicazione. Uno scenario di test ha lo scopo di garantire che il software funzioni come previsto e che tutte le sue caratteristiche e funzioni funzionino correttamente. In genere, gli sviluppatori o i tester software creano questi scenari di test per garantire che il software soddisfi le specifiche e i requisiti specificati.
Quando viene eseguito uno scenario di test, il software esegue una serie di controlli per verificare di produrre i risultati desiderati. A questo scopo, un test svolge le seguenti attività:
- Verifica. Il processo di controllo rigoroso del software per garantire che funzioni senza errori. Determinare se il prodotto creato soddisfa tutti i requisiti non funzionali necessari e raggiunge correttamente lo scopo previsto è fondamentale. La domanda alla quale risponde è: "Stiamo realizzando il prodotto in modo corretto?".
- Convalida. Il processo per garantire che il prodotto software soddisfi gli standard necessari o i requisiti di alto livello. Occorre verificare se il prodotto effettivo è in linea con quello previsto. Essenzialmente, stiamo rispondendo alla domanda: "Stiamo realizzando il prodotto giusto per le esigenze dell'utente?".
Supponiamo che il programma non riesca a fornire il risultato previsto. In questo caso, lo scenario di test sarà il messaggero, in modo da segnalare un risultato non riuscito e lo sviluppatore o il tester dovrà esaminare il problema e trovare una soluzione. Considera i controlli e le azioni come i percorsi seguiti dal computer, indipendentemente dal tipo di test. I gruppi di dati di input o le condizioni utilizzati per il controllo sono denominati "classi di equivalente". Dovrebbero ottenere un comportamento o risultati simili dal sistema sottoposto a test. I percorsi specifici eseguiti all'interno di un test possono variare, ma dovrebbero corrispondere alle attività e alle asserzioni eseguite nel test.
Percorsi di test: tipi tipici di scenari di test
Nello sviluppo software, uno scenario di test è uno scenario di esecuzione di codice in cui è previsto e testato un determinato comportamento. In genere, sono tre gli scenari in base ai quali creare scenari di test.
Il primo è il più noto e probabilmente stai già utilizzando. Si tratta del percorso felice, noto anche come "scenario felice" o "percorso d'oro", che definisce il caso d'uso più comune della funzionalità, dell'applicazione o della modifica, ovvero il modo in cui dovrebbe funzionare per il cliente.
Il secondo percorso di test più importante da affrontare nei tuoi scenari di test viene spesso tralasciato in quanto crea disagio, come potrebbe suggerire il suo nome. Si tratta del "percorso spaventoso" o, in altre parole, del test negativo. Questo percorso ha come target scenari che causano il funzionamento non corretto del codice o uno stato di errore. Testare questi scenari è particolarmente importante se hai casi d'uso altamente vulnerabili che pongono un rischio elevato per gli stakeholder o gli utenti.
Esistono altri percorsi che potresti conoscere e utilizzare, ma in genere sono meno utilizzati. La seguente tabella riassume questi dati:
| Percorso di test | Spiegazione |
|---|---|
| Percorso arrabbiato | Questo genera un errore, ma previsto; ad esempio, se vuoi assicurarti che la gestione degli errori funzioni correttamente. |
| Percorso inadempiente | Questo percorso si occupa di tutti gli scenari relativi alla sicurezza che la tua applicazione deve soddisfare. |
| Sentiero desolato | Il percorso che verifica lo scenario nell'applicazione non dispone di dati sufficienti per funzionare, ad esempio test di valori nulli. |
| Percorso dimenticato | Testare il comportamento della tua applicazione con risorse insufficienti, ad esempio attivando una perdita di dati. |
| Percorso indeciso | Test con un utente che sta provando a eseguire azioni o a seguire storie utente nella tua applicazione, ma non ha completato quei flussi di lavoro. Questo potrebbe verificarsi, ad esempio, quando l'utente interrompe il flusso di lavoro. |
| Percorso greedy | Provare a fare dei test utilizzando enormi quantità di input o dati. |
| Percorso stressante | Provare a caricare un'applicazione con qualsiasi mezzo necessario fino a quando non funziona più (simile a un test di carico). |
Esistono diversi metodi per classificare questi percorsi. Due approcci comuni sono:
- Partizionamento di equivalenza: Metodo di test che classifica gli scenari di test in gruppi o partizioni e, di conseguenza, aiuta a creare classi di equivalenza. Questo 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 specifica classe di equivalenza devono presentare un comportamento identico, puoi ridurre il numero di scenari di test. Scopri di più sul partizionamento delle equivalenze.
- Analisi dei limiti. Un metodo di test, noto anche come analisi dei valori dei confini, che esamina i limiti o gli estremi dei valori di input per individuare potenziali problemi o errori che potrebbero emergere in corrispondenza dei limiti di capacità o vincoli del sistema.
Best practice: scrittura di scenari di test
Uno scenario di test classico scritto da un tester conterrà dati specifici per aiutarti a comprendere il contenuto del test che vuoi condurre e, ovviamente, a eseguirlo. Un tester tipico documenta le attività di test in una tabella. In questa fase possiamo utilizzare due schemi, che ci aiutano a strutturare gli scenari di test e, in seguito, anche i test stessi:
- Modello Disponi, agisce, asserisce. Il modello di test "disponi, agisci, afferma" (noto anche come "AAA" o "Triple A") è un modo di organizzare i test in tre fasi distinte: disposizione e esecuzione del test e, ultimo ma non meno importante, traendo le conclusioni.
- Sequenza determinata, quando e quindi. Questo modello è simile a quello AAA, ma ha alcune radici nello sviluppo basato sul comportamento.
Gli articoli futuri forniranno maggiori dettagli su questi modelli, non appena tratteremo la struttura di un test stesso. Se in questa fase vuoi approfondire questi pattern, dai un'occhiata a questi due articoli: Arrange-Act-Assert: A pattern for write valide test e Providen-When- Then.
In base a quanto appreso da questo articolo, la seguente tabella riassume un esempio classico:
| Informazione | Spiegazione |
|---|---|
| Prerequisiti | Tutto ciò che deve essere fatto prima di scrivere il test. |
| Oggetto in fase di test | Cosa deve essere verificato? |
| Dati di input | Variabili e relativi valori. |
| Passaggi da eseguire | Tutte le azioni che farai per realizzare il test: tutte le azioni o le interazioni che esegui nei test. |
| Risultato previsto | Che cosa deve accadere e quali aspettative devono essere soddisfatte. |
| Risultato effettivo | Che cosa succede effettivamente. |
Nei test automatici, non è necessario documentare tutti questi scenari di test nel modo necessario a un tester, anche se è indubbiamente utile farlo. Se fai attenzione, puoi trovare tutte queste informazioni nel tuo test. Traduciamo questo classico scenario di test in un test automatizzato.
| Informazione | Traduzione nell'automazione dei test |
|---|---|
| Prerequisiti | Tutto ciò di cui hai bisogno, come organizzare il test e pensare a cosa viene dato per realizzare lo scenario del test. |
| Oggetto in fase di test | Questo "oggetto" può essere un'applicazione, un flusso, un'unità o un componente in fase di test. |
| Dati di input | Valori dei parametri. |
| Passaggi da eseguire | Tutte le azioni e i comandi eseguiti all'interno del tuo test, le azioni su cui esegui azioni e la scoperta di cosa succede quando esegui determinate operazioni. |
| Risultato previsto | L'affermazione che utilizzi per convalidare la tua applicazione, ovvero gli elementi su cui dichiari nella stessa. |
| Risultato effettivo | Il risultato del test automatico. |