Test del software - Documentazione
La documentazione di test implica la documentazione di artefatti che dovrebbero essere sviluppati prima o durante il test del software.
La documentazione per il test del software aiuta a stimare lo sforzo di test richiesto, la copertura del test, il monitoraggio / tracciamento dei requisiti, ecc. Questa sezione descrive alcuni degli artefatti documentati di uso comune relativi al test del software come:
- Piano di test
- Scenario di prova
- Caso di prova
- Matrice di tracciabilità
Piano di test
Un piano di test delinea la strategia che verrà utilizzata per testare un'applicazione, le risorse che verranno utilizzate, l'ambiente di test in cui verranno eseguiti i test ei limiti del test e la pianificazione delle attività di test. In genere, il responsabile del team di garanzia della qualità sarà responsabile della stesura di un piano di test.
Un piano di test include quanto segue:
- Introduzione al documento Piano di prova
- Presupposti durante il test dell'applicazione
- Elenco dei casi di test inclusi nel test dell'applicazione
- Elenco delle caratteristiche da testare
- Che tipo di approccio utilizzare durante il test del software
- Elenco dei risultati che devono essere testati
- Le risorse assegnate per testare l'applicazione
- Eventuali rischi coinvolti durante il processo di test
- Un programma di attività e traguardi da raggiungere
Scenario di prova
È un'istruzione di una riga che notifica quale area dell'applicazione verrà testata. Gli scenari di test vengono utilizzati per garantire che tutti i flussi di processo siano testati dall'inizio alla fine. Una particolare area di un'applicazione può avere un minimo di uno scenario di test fino a poche centinaia di scenari a seconda dell'entità e della complessità dell'applicazione.
I termini "scenario di test" e "scenari di test" sono usati in modo intercambiabile, tuttavia uno scenario di test ha diversi passaggi, mentre uno scenario di test ha un singolo passaggio. Visti da questa prospettiva, gli scenari di test sono casi di test, ma includono diversi casi di test e la sequenza in cui dovrebbero essere eseguiti. A parte questo, ogni test dipende dall'output del test precedente.
Caso di prova
I casi di test comportano una serie di passaggi, condizioni e input che possono essere utilizzati durante l'esecuzione di attività di test. L'intento principale di questa attività è garantire se un software supera o fallisce in termini di funzionalità e altri aspetti. Esistono molti tipi di casi di test come casi di test funzionali, negativi, di errore, logici, casi di test fisici, casi di test dell'interfaccia utente, ecc.
Inoltre, i casi di test vengono scritti per tenere traccia della copertura dei test di un software. In generale, non ci sono modelli formali che possono essere utilizzati durante la scrittura del caso di test. Tuttavia, i seguenti componenti sono sempre disponibili e inclusi in ogni caso di test:
- ID caso di test
- Modulo prodotto
- Versione del prodotto
- Cronologia delle revisioni
- Purpose
- Assumptions
- Pre-conditions
- Steps
- Risultato previsto
- Risultato effettivo
- Post-conditions
Molti casi di test possono essere derivati da un singolo scenario di test. Inoltre, a volte vengono scritti più casi di test per un singolo software, noti collettivamente come suite di test.
Matrice di tracciabilità
La matrice di tracciabilità (nota anche come matrice di tracciabilità dei requisiti - RTM) è una tabella utilizzata per tracciare i requisiti durante il ciclo di vita dello sviluppo del software. Può essere utilizzato per la traccia in avanti (cioè dai requisiti alla progettazione o alla codifica) o all'indietro (cioè dalla codifica ai requisiti). Esistono molti modelli definiti dall'utente per RTM.
Ogni requisito nel documento RTM è collegato al suo caso di test associato in modo che il test possa essere eseguito secondo i requisiti menzionati. Inoltre, anche l'ID bug è incluso e collegato ai requisiti e al test case associati. Gli obiettivi principali di questa matrice sono:
- Assicurati che il software sia sviluppato secondo i requisiti menzionati.
- Aiuta a trovare la causa principale di qualsiasi bug.
- Aiuta a tracciare i documenti sviluppati durante le diverse fasi di SDLC.