Che cos’è, a cosa serve ed esempio di Scenario di test
Scenario di test
Lo Scenario di test è un’attività di Collaudo del software o testing software che utilizza gli scenari: storie ipotetiche che aiutano il tester a lavorare ad un problema complesso o a testare un sistema. Lo scenario di test ideale è una storia credibile, complessa, avvincente o motivante, il quale esito sia facile da valutare. Questi test sono solitamente diversi dai casi di test in quanto questi sono singoli passi, mentre uno scenario copre un certo numero di passi.
Lo scenario tipico di test
Lo scenario tipico nel quale ci si trova ad operare come tester, non è sempre ottimale: in molti casi, ci si trova dinanzi ad una scarsa conoscenza del prodotto da esaminare e si è in possesso di una sommaria documentazione talvolta obsoleta; tutto ciò, porta i tester a spendere una parte iniziale del proprio tempo a comprendere le caratteristiche del prodotto e le sue funzionalità, il che può richiedere del tempo considerevole, soprattutto in presenza di progetti complessi.
Dopo questa fase, è possibile passare ad elencare ordinatamente le funzionalità, in modo da avere un quadro completo del prodotto; partendo da questi aspetti, è ora possibile identificare i test per ognuno di essi; ad esempio, in presenza di un campo che accetta valori in input (come un form di registrazione clienti), verificheremo che non vengano accettati dati non validi (caratteri ASCII particolari), che non vengano accettate stringhe troppo lunghe o errate o incomplete. Occorre evidenziare come tale fase non sia operativa, ma esclusivamente descrittiva, e costituisca un’indispensabile fase di lavoro, sulla quale verranno eseguiti i test. La documentazione può anche risultare piuttosto lunga, ma tale approccio permetterà di ottenere un quadro più completo e preciso della situazione.
Il passaggio alla creazione dei test-case è implicito; ciascuna prova da effettuare sarà implementata fisicamente in un caso di test; ad esempio, la verifica di un campo di input che non dovrebbe accettare valori troppo lunghi verrà testata inserendo valori non corretti, al fine di validarne il funzionamento. Ciascun test-case, sarà costituito ad esempio da:
- una parte descrittiva del test
- i valori che devono essere eventualmente inseriti
- output atteso
- output ottenuto
- esito della prova
La forma presentata si riferisce al caso di un test-case singolo: nel caso vi siano test multipli (ad esempio immissione di caratteri non validi) che appartengono alla medesima categoria (inserimento valori) la descrizione sarà globale, e non accompagnerà i singoli test in quanto renderebbe la documentazione ridondante. Le descrizioni delle attività, degli errori riscontrati, dell’obbiettivo del test dovrebbero essere sintetiche ma chiare, in piano rispetto del concetto di usabilità della documentazione.
Questa organizzazione dei test-case non è obbligatoria, ma è esclusivamente personale; può tuttavia essere utilizzata come base per la creazione di un template generale da utilizzare per tutti i progetti. Ad ogni test-case, possono essere associati uno o più bug riscontrati durante le prove, che verranno segnalati agli sviluppatori secondo le modalità previste (mail o altre risorse).
La documentazione finale sarà costituita dall’intero piano di test, che verrà poi approvato dai responsabili del progetto dietro previa visione dei responsabili della qualità, una volta risolte tutte le defezioni del codice. Successivi errori eventualmente segnalati dai clienti o da successivi test, porteranno ad aggiornamenti della documentazione oppure ad integrazione di ulteriori documenti. La redazione del Piano di test dovrà seguire il template di qualità adottato dall’azienda, e la casistica di test non dovrà perdersi in dettagli di scarsa rilevanza per l’utente.
Se i tester dispongono inizialmente di un piano di test obsoleto che deve essere aggiornato, è opportuno che questo piano di test venga tenuto sino all’approvazione del nuovo piano, al fine di confrontare quanto fatto con quanto esistente; solo successivamente si provvederà ad una sua eliminazione definitiva. Con l’approvazione del piano di test, si chiude l’attività di testing del prodotto, a meno che non venga disposto di continuare saltuariamente una attività di test organizzata eventualmente una volta alla settimana, al fine di verificare l’esistenza di bug latenti, o testare lo stress del prodotto all’utilizzo dei consumatori.
