Test agili - Tecniche
Le tecniche di test dei test tradizionali possono essere utilizzate anche nei test Agile. Oltre a questi, nei progetti Agile vengono utilizzate tecniche e terminologie di test specifiche Agile.
Base di prova
Nei progetti agili, il backlog del prodotto sostituisce i documenti di specifica dei requisiti. I contenuti del product backlog sono normalmente storie di utenti. Anche i requisiti non funzionali vengono presi in considerazione nelle storie degli utenti. Pertanto, la base di prova nei progetti Agile è la user story.
Per garantire test di qualità, anche quanto segue può essere considerato come base di test:
- Esperienza da iterazioni precedenti dello stesso progetto o progetti precedenti.
- Funzioni esistenti, architettura, design, codice e caratteristiche di qualità del sistema.
- Dati difettosi dai progetti attuali e passati.
- Feedback del cliente.
- Documentazione utente.
Definizione done
La Definizione di Fatto (DoD) è il criterio utilizzato nei progetti Agile per garantire il completamento di un'attività nello Sprint backlog. Il DoD può variare da un team Scrum all'altro, ma dovrebbe essere coerente all'interno di un team.
DoD è un elenco di controllo delle attività necessarie che assicurano l'implementazione di funzioni e caratteristiche in una user story insieme ai requisiti non funzionali che fanno parte della user story. Una user story raggiunge la fase Completato dopo che tutti gli elementi nell'elenco di controllo DoD sono stati completati. Un DoD è condiviso da tutto il team.
Un tipico DoD per una user story può contenere:
- Criteri dettagliati di accettazione verificabili
- Criteri per garantire la coerenza della User Story con le altre nell'iterazione
- Criteri specifici relativi al prodotto
- Aspetti del comportamento funzionale
- Caratteristiche non funzionali
- Interfaces
- Requisiti dei dati di prova
- Copertura del test
- Refactoring
- Requisiti di revisione e approvazione
Oltre al DoD per le storie degli utenti, è richiesto anche il DoD:
- ad ogni livello di test
- per ogni caratteristica
- per ogni iterazione
- per il rilascio
Informazioni sul test
Un tester deve avere le seguenti informazioni sul test:
- Storie degli utenti che devono essere testate
- Criteri di accettazione associati
- Interfacce di sistema
- Ambiente in cui si prevede che il sistema funzioni
- Disponibilità degli strumenti
- Copertura del test
- DoD
Nei progetti Agile, poiché il test non è un'attività sequenziale e i tester dovrebbero lavorare in modalità collaborativa, è responsabilità del tester:
- Ottenere le informazioni necessarie sui test su base continuativa.
- Identifica le lacune informative che influenzano i test.
- Risolvi le lacune in collaborazione con altri membri del team.
- Decidi quando viene raggiunto un livello di prova.
- Garantire l'esecuzione di test appropriati nei momenti pertinenti.
Progettazione di test funzionali e non funzionali
Nei progetti Agile, è possibile utilizzare le tecniche di test tradizionali, ma l'attenzione è rivolta ai test iniziali. I casi di test devono essere in atto prima dell'inizio dell'implementazione.
Per la progettazione di test funzionali, i tester e gli sviluppatori possono utilizzare le tradizionali tecniche di progettazione di test Black Box come:
- Partizionamento di equivalenza
- Analisi del valore limite
- Tabelle delle decisioni
- Transizione di stato
- Albero delle classi
Per la progettazione di test non funzionali, poiché anche i requisiti non funzionali fanno parte di ogni user story, le tecniche di progettazione di test black box possono essere utilizzate solo per progettare i casi di test pertinenti.
Test esplorativi
Nei progetti Agile, il tempo è spesso il fattore limitante per l'analisi e la progettazione dei test. In questi casi, le tecniche di test esplorativo possono essere combinate con le tecniche di test tradizionali.
Il test esplorativo (ET) è definito come apprendimento simultaneo, progettazione di test ed esecuzione di test. In Exploratory Testing, il tester controlla attivamente la progettazione dei test mentre vengono eseguiti e utilizza le informazioni ottenute durante il test per progettare nuovi e migliori test.
Il test esplorativo è utile per accogliere i cambiamenti nei progetti Agile.
Test basati sul rischio
Il test basato sul rischio è un test basato sul rischio di fallimento e mitiga i rischi utilizzando tecniche di progettazione del test.
Un rischio di qualità del prodotto può essere definito come un potenziale problema con la qualità del prodotto. I rischi per la qualità del prodotto includono:
- Rischi funzionali
- Rischi di prestazioni non funzionali
- Rischi di usabilità non funzionale
L'analisi del rischio deve essere eseguita per valutare la probabilità (verosimiglianza) e l'impatto di ciascun rischio. Quindi, i rischi hanno la priorità:
- Rischi elevati richiedono test approfonditi
- Rischi bassi richiedono solo test rapidi
I test sono progettati utilizzando tecniche di test appropriate basate sul livello di rischio e sulla caratteristica di rischio di ciascun rischio. Vengono quindi eseguiti test per mitigare i rischi.
Test di adattamento
I Fit Test sono test di accettazione automatizzati. Gli strumenti Fit e FitNesse possono essere utilizzati per automatizzare i test di accettazione.
FIT utilizza JUnit, ma estende la funzionalità di test. Le tabelle HTML vengono utilizzate per visualizzare i casi di test. Fixture è una classe Java dietro la tabella HTML. L'apparecchiatura prende il contenuto della tabella HTML ed esegue i casi di test sul progetto in fase di test.