Quando si parla di testing, quasi sempre si pensa a procedure che operano su un programma o comunque su uno scheletro di una applicazione, spesso purtroppo si tralascia la fase di testing durante la raccolta dei requisiti.
Dato che nella fase di raccolta requisiti non si ha ancora nemmeno una singola riga di codice, viene naturale pensare che non sia possibile “testare” nulla, ma invece è importante eseguire un cicolo di test anche sui requisiti stessi, anche perchè i bug che si annidano nei requisiti sono quelli che portano più danni al progetto.
La prima cosa che si deve verificare è che le specifiche raccolte individuino realmente il problema, la domanda è “questi requisiti sono quelli giusti?”. Rispondere a questa domanda è difficile, quello che si dovrebbe fare è avere raccolto i requisiti su di un software o comunque in modo omogeneo, e rivederli assieme agli stakeholder, per capire se si è dimenticato qualche aspetto fondamenale e se si è ben compreso il nocciolo del problema.
In questo scenario i casi d’uso sono molto utili, perchè presentano una descrizione testuale dei requisiti, possono essere letti dal cliente e non necessitano di prerequisiti particolari per essere compresi. Durante il test dei casi d’uso particolare attenzione va prestata non tanto al percorso principale di successo (Main Success Scenario), ma piuttosto alle estensioni e alle eccezioni.
Un esempio pratico potrebbe essere il seguente. Se abbiamo un caso d’uso relativo ad una picking list di un magazziniere potremmo avere un main success scenario di questo tipo
- Il magazziniere chiede al sistema l’ordine successivo da processare
- Il sistema invia l’ordine costituito da una lista di oggetti
- Il magazziniere preleva i pezzi in sequenza, per ogni pezzo legge il suo codice a barre
- il sistema valida il codice a barre ed indica la quantità prelevata
- Si ripetono le operazioni 3 e 4 fino a che l’ordine non è completo
- Quando l’ordine è completo il sistema mostra un segnale a schermo ed impedisce la lettura di ulteriori pezzi
- Il magazzinere impacchetta i pezzi in un imballo e legge il codice dell’imballo
- Il sistema chiude la spedizione.
In questo caso testare questo caso d’uso consiste prima di tutto nel verificare con un magazziniere che questa sia effettivamente la sequenza di operazioni necessaria per l’invio di un ordine, successivamente è necessario iniziare a verificare i percorsi alternativi. Il testing di un caso d’uso spesso consiste semplicemente nel pensare cosa “può andare storto” nel main success scenario, al fine di individuare percorsi alternativi. In pratica si inizia a porre domande di questo tipo:
- Cosa succede se il magazziniere legge un pezzo che non è in ordine?
- Cosa succede se la connessione del palmare cade ed il device non riesce più a raggiungere il server principale?
- Cosa succede se il magazziniere dimentica di leggere un codice a barre e quindi vede nel suo cestino tutti i pezzi ma il sistema sostiene che ne manca ancora uno?
- Cosa succede se l’ultimo pezzo disponibile di un dato oggetto ha il codice a barre rovinato e non riesce ad essere letto dal lettore?
Pensare a questi problemi durante la fase di raccolta requisiti e catalogarli sul caso d’uso come percorso alternativo è una buona pratica, perchè è possibile ancora affrontare i problemi da un punto di vista concettuale. Quello che spesso accade invece è che le problematiche vengono rilevate con i primi prototipi, o ancora peggio con il software in produzione, aumentando in maniera enorme il costo di risoluzione.
In altre situazioni il test può essere costituito da una simulazione su carta. Se ad esempio si deve dialogare con un vecchio sistema legacy e si è scelto di utilizzare una tabella di un database come canale di scambio informazioni, è utile iniziare a simulare su carta una sequenza di dialogo. Troppo spesso in questi casi la specifica cita solamente “verrà usata una tabella di un database condiviso per scambiare dati” poi ci si accorge durante lo sviluppo che si richiede una trasmissione veloce e quasi real-time, oppure che il processo logico scelto per la comunicazione ha delle falle. Anche in questo caso è utile “testare” la comunicazione prendendo un foglio di carta o un documento ed iniziando a simulare passo dopo passo cosa viene scritto nella tabella di scambio, chiedendo poi ai responsabili di entrambe le parti se pensano che ci possa essere un problema.
Ujna attenta verifica/testing dei requisiti può evitare molte grane in fase di sviluppo. :)
Alk.
