Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 601, comments - 1063, trackbacks - 88

My Links

News

Gian Maria Ricci
Mvp Logo
CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

Test dei requisiti

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

  1. Il magazziniere chiede al sistema l’ordine successivo da processare
  2. Il sistema invia l’ordine costituito da una lista di oggetti
  3. Il magazziniere preleva i pezzi in sequenza, per ogni pezzo legge il suo codice a barre
  4. il sistema valida il codice a barre ed indica la quantità prelevata
  5. Si ripetono le operazioni 3 e 4 fino a che l’ordine non è completo
  6. Quando l’ordine è completo il sistema mostra un segnale a schermo ed impedisce la lettura di ulteriori pezzi
  7. Il magazzinere impacchetta i pezzi in un imballo e legge il codice dell’imballo
  8. 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.

DotNetKicks Image

Print | posted on martedì 24 agosto 2010 9.42 | Filed Under [ Analisi ]

Feedback

Gravatar

# re: Test dei requisiti

Bisogna distinguere testing da QA, test da collaudi, e attivita' primarie da attivita' ausiliarie.

Bisogna ricordare che anche Analisi produce i suoi deliverables, ovvero appunto i documenti di analisi: *c'e'* un "codice" da testare e collaudare.

Bisogna distinguere analisi concettuale da analisi tecnica, raccolta requisiti da modellazione del sistema (requisiti da specifiche), dominio del problema da dominio della soluzione.

Bisogna ricordare che i Casi d'Uso *non* sono lo strumento ideale per fare raccolta requisiti (analisi concettuale), si prestano meglio alla modellazione di sistema (analisi tecnica).

Bisogna ricordare che sono i diagrammi, non il testo, l'ausilio principale del lavoro di analisi, sia concettuale che tecnica.

Bisogna ricordare che, quando si parla di Analisi, il primo problema non e' capire come fare a sottoporla a test, il primo problema e' farla, e farla in modo decente.

-LV
24/08/2010 16.16 | LudovicoVan
Gravatar

# re: Test dei requisiti

Sui casi d'uso non sono daccordo al 100%, io li trovo molto utili per "costringere" gli stakeholder a ragionare su qualche cosa. Ragionare su una sequenza di passi da effettuare e sui percorsi alternativi solitamente fa nascere discussioni interessanti. Trovo infatti che i casi d'uso siano ben utilizzabili sia nella parte di analisi concettuale sia tecnica.

A mio avviso i vari livelli di profondità dei casi d'uso (white, blue ed indigo per usare la notazione di cockburn) determinano la loro collocazione. I casi d'uso livello utente (o blu) da una parte sono sicuramente nel dominio della soluzione e sono usati principalmente per ladocumentazione tecnica, ma dall'altra parte gli stakeholder riescono a leggerli e sono un buono spunto per fare emergere particolari relativi alla raccolta requisiti. Ad esempio leggere la sequenza di passi precedenti e sentirsi dire dal magazziniere "cosa succede se non ho rete, perchè in alcuni punti della fabbrica la rete arriva male" elicita un requisito, ovvero il sistema deve lavorare anche in situazioni di mancanza di rete.

Sull'ultimo punto, siamo sempre più daccordo, troppo spesso il problema è che l'analisi non viene fatta :( e non c'è nulla da testare.

Alk.
24/08/2010 16.38 | alkampfer@nablasoft.com
Gravatar

# re: Test dei requisiti

> Sui casi d'uso non sono daccordo al 100%

Forse neanch'io, in fondo sono meglio di niente.

> siamo sempre più daccordo, troppo spesso il problema è che l'analisi non viene fatta

Semmai siamo al solito qui pro quo: io continuo a dire che viene fatta poco e *male*.

Una nota piu' tecnica: L'adozione dei casi d'uso in sede di analisi concettuale e' una forzatura che si comprende nel contesto del movimento per l'"object orientation sopra tutto": ovvero tutto sempre sottosopra.

-LV
24/08/2010 16.55 | LudovicoVan
Gravatar

# re: Test dei requisiti

>Semmai siamo al solito qui pro quo: io continuo a dire che viene fatta poco e *male*.

Si, più che altro mi è capitato spesso che il prodotto dell'analisi sia più che altro fuffa, oppure ancora peggio, un tentativo di far firmare un documento al cliente per poi dire "hai firmato l'analisi, se vuoi una modifica devi pagare". Mi piacerebbe qui avere esperienze dagli altri.

>>
Una nota piu' tecnica: L'adozione dei casi d'uso in sede di analisi concettuale e' una forzatura che si comprende nel contesto del movimento per l'"object orientation sopra tutto": ovvero tutto sempre sottosopra.
>>

Non necessariamente, qualsiasi strumento che mi permetta di ragionare con gli stakeholder per evitare incomprensioni è il benvenuto. Spesso accade che ragionando sopra l'analisi tecnica emergano problemi legati ai requisiti concettuali e spesso accade leggendo i casi d'uso.
A quel punto non signfica che il caso d'uso diventi parte dell'analisi concettuale, ma semplicemente mi permette di ragionare ad un livello più concreto, dove il cliente/stakeholder si trova meglio.

alk.
24/08/2010 17.14 | alkampfer@nablasoft.com
Comments have been closed on this topic.

Powered by: