Esame dell'approccio del test, degli elementi di test di destinazione e valutazione delle esigenze
Scopo:
|
Comprensione di come verranno determinati i test, e le conseguenze che avranno su come si dovranno
implementare le suite di test specifiche per determinare gli elementi di test di destinazione.
|
Partendo da un'analisi del piano di test per la determinazione delle esigenze di valutazione, considerare come la
valutazione della misura della qualità della verifica e del software possa essere determinata utilizzando l'approccio
di test definito. Considerare tutte le esigenze particolari relative agli elementi di test di destinazione specifici.
|
Esame dei meccanismi di verificabilità e degli elementi di supporto
Scopo:
|
Comprensione degli elementi di verificabilità disponibili e dei meccanismi che supportano e dei benefici
che offrono.
|
Analizzare i meccanismi utili all'abilitazione della verifica in questo ambiente, ed identificare gli elementi di
verificabilità specifici che tali meccanismi implementano. Ciò comprende l'analisi delle risorse quali qualsiasi
libreria di funzioni che sia stata sviluppata dal team di test e gli stub implementati dal team di sviluppo.
La verificabilità viene raggiunta da una combinazione tra il software in fase di sviluppo da verificare e la
definizione di un approccio di test che ne supporta la verifica in modo appropriato. La verificabilità è un aspetto
importante dello sviluppo delle risorse del team di test, tanto quanto è una parte importante dell'impegno dello
sviluppo del software. Il raggiungimento della verificabilità (la possibilità di verificare un prodotto software in
modo efficiente) solitamente prevederà una combinazione di quanto segue:
-
abilitatori della verificabilità forniti da tool di automatizzazione del test
-
tecniche specifiche per creare gli script di test del componente
-
librerie di funzioni che separano ed incapsulano la complessità dalla definizione procedurale del test di base
negli script di test, fornendo un punto centralizzato di controllo e modifica.
La suite di test corrente ha i requisiti necessari alla sua distribuzione? In caso affermativo, utilizzare gli elementi
di verificabilità che supportano la distribuzione. Tali elementi saranno solitamente delle funzioni di tool di
automatizzazione di supporto specifici, che distribuiranno la suite di test, eseguirli in remoto e recuperare il log di
test ed i loro output per la determinazione centralizzata dei risultati.
La suite di test corrente deve essere eseguita in simultanea con altre suite di test? In caso affermativo, utilizzare
gli elementi di verificabilità che supportano la simultaneità. Tali elementi saranno solitamente una combinazione di
tool di supporto specifici e funzioni di un programma di utilità, che permettono alla suite di test di essere eseguita
in simultanea su differenti macchine fisiche. La simultaneità richiede una attenda progettazione e gestione dei dati di
test, per assicurare che non si verifichino effetti collaterali inattesi o non pianificati, quali due test simultanei
che aggiornino lo stesso record di un dato.
|
Creazione di una struttura di suite di test iniziale
Scopo:
|
Definire la suite di test da implementare.
|
Elencare una o più suite di test che (quando eseguite) forniranno un risultato completo e significativo al team di
test, consentendo la creazione di un report per gli stakeholder. Cercare un equilibrio tra i dati sufficienti a fornire
specifiche informazioni al team di progetto ed un livello di dettaglio che li renderebbe ingestibili.
In presenza di script di test, si assembreranno le suite di test e le parti relative autonomamente, per poi passare il
lavoro di stabilizzazione ad un implementatore della suite di test.
Per le suite di test che richiedono la creazione di nuovi script di test, bisognerà dare un'indicazione degli script di
test o delle suite di test che verranno referenziate da questa. Se è facile elencarle, procedere. Se non lo è, si potrà
semplicemente fornire una breve descrizione che evidenzi la copertura dei contenuti prevista della suite di test
principale e lasciare che sia l'implementatore a decidere quali script di test includere.
|
Adattamento della struttura della suite di test perché rifletta l'organizzazione del team ed i vincoli dei tool
Scopo:
|
Perfezionare la struttura della suite di test in modo che corrisponda alle assegnazioni delle
responsabilità al team.
|
Potrebbe essere necessario suddividere ulteriormente o strutturare nuovamente la suite di test identificata in modo da
adattarla alla WBS (Work Breakdown Structure) a cui il team lavora. Ciò aiuterà a ridurre il rischio che si verifichino
dei conflitti di accesso durante lo sviluppo della suite di test. A volte i tool di automazione dei test possono
inserire dei vincoli su come i singoli lavorano con le risorse di automazione, strutturare nuovamente la suite di test
per risolvere questa problematica.
|
Identificazione dei meccanismi di comunicazione tra script di test
Scopo:
|
Identificare dati di test e stati del sistema che devono essere condivisi o passati tra gli script di test.
|
In molti casi le suite di test possono semplicemente richiamare gli script di test in un determinato ordine. Ciò
assicurerà, nella maggior parte dei casi, che lo stato del sistema corretto venga passato da uno script di test al
successivo.
Tuttavia, in alcune classi di sistema, i dati di run-time dinamici vengono generati dal sistema o sono derivati come
risultato della transazione in essi eseguita. Ad esempio, in un sistema di accettazione di ordini e di distribuzione,
ogni volta che si inserisce un ordine viene generato un numero d'ordine univoco. Per permettere ad uno script di test
automatizzato di distribuire un ordine, sarà necessario che lo script di test precedente in cui è stato immesso un
ordine, ne registri il numero univoco generato dal sistema e lo passi allo script di test della distribuzione.
In casi come questo sarà necessario considerare quali meccanismi di comunicazione tra script di test sarà necessario
utilizzare. Le alternative tipiche comprendono parametri passati, la scrittura e lettura di valori in un file e
l'utilizzo di variabili di run time globali. Ciascuna strategia ha i suoi pro e contro che la rendono più o meno
adeguata ad una determinata situazione.
|
Definizione delle dipendenze iniziali tra elementi della suite di test
Scopo:
|
Identificare e registrare le dipendenze di run time tra gli elementi della suite di test.
|
Questa è principalmente collegata alla sequenza degli script di test ed anche alla suite di test di esecuzione di run
time. I test definiti per essere eseguiti senza le dipendenze corrette, corrono il rischio di terminare con errori o di
segnalazione dati anomali.
|
Modellazione visiva dell'architettura di implementazione dei test
Scopo:
|
Creare un diagramma che descriva e spieghi come si realizza l'implementazione del test.
|
Se si possiede un tool di modellazione e disegno UML, si potrà decidere di creare un diagramma del modello di
implementazione del test, che descriva gli elementi chiave del software del test automatizzato. Similmente si potranno
rappresentare con un diagramma alcuni aspetti fondamentali della architettura di automazione del test.
Un altro approccio è quello di disegnare questi diagrammi su una lavagna visibile da tutto il team di test.
|
Perfezionamento della struttura della suite di test
Scopo:
|
Effettuare le regolazioni necessarie per mantenere l'integrità dell'implementazione dei test.
|
Con l'avanzamento di un progetto è possibile che le suite di test vengano modificate: vi si potranno aggiungere nuovi
script di test, aggiornarne di già esistenti, riorganizzarli o cancellarne qualcuno. Queste modifiche rappresentano una
fase normale nel mantenimento della suite di test e bisogna accettarla piuttosto che evitarla.
Se non si aggiorna in modo efficace la suite di test, queste diverranno presto obsolete. Abbandonate per pochi build
sarà più facile ricrearle che rigenerarle. Consultare la sezione Ulteriori informazioni:
nella tabella di intestazione di questa pagina per ulteriori linee guida sulla gestione delle suite di test
automatizzate.
|
Gestione delle relazioni di tracciabilità
Scopo:
|
Abilitare l'esecuzione della segnalazione dell'analisi d'impatto e della valutazione sugli elementi
tracciati.
|
Utilizzando i requisiti di tracciabilità evidenziati nel piano di test, aggiornare le relazioni di tracciabilità come
richiesto.
|
Valutazione e verifica dei risultati
Scopo:
|
Verificare che il compito sia stato completato in modo appropriato e che i prodotti di lavoro risultanti
siano accettabili.
|
Una volta completato il lavoro è bene verificare che questo sia stato di buona qualità, e che non si siano consumate
unicamente grosse quantità di carta. È necessario valutare se il proprio lavoro sia stato all'altezza, e che sia
completo abbastanza da essere utile ai membri del team che l'utilizzeranno in seguito. Dove possibile, utilizzare
l'elenco di controllo fornito da RUP per verificarne la qualità e la completezza.
Richiedere ai componenti del team di concentrarsi sul flusso di operazioni che hanno come input il vostro lavoro e
partecipare all'analisi effettuata durante il suo corso. Procedere in questo modo mentre si ha ancora tempo a
disposizione per prendere decisioni e discutere delle loro considerazioni. È inoltre necessario considerare il proprio
lavoro nei confronti dei prodotti di lavoro di input chiave, per assicurarsi che siano stati rappresentati in modo
accurato e sufficiente. Potrebbe essere utile chiedere all'autore del prodotto di lavoro di input di revisionare il
vostro lavoro su queste basi.
Tenere presente che RUP è un processo di produzione iterativo e che in molti casi i prodotti di lavoro evolvono nel
tempo. Su questa base è spesso non necessario o addirittura controproducente, definire in modo completo un prodotto di
lavoro che verrà utilizzato solo parzialmente o affatto, nel lavoro immediatamente successivo. Questo perché vi è
un'alta probabilità che il contesto che circonda il prodotto di lavoro possa cambiare e che i presupposti definiti,
quando questo è stato creato, possano dimostrarsi errati prima del suo utilizzo, portando così al dispendio inutile di
sforzi ed ad ulteriori costi di rilavorazione. Non effettuare inoltre troppi cicli sulla presentazione per evitare il
detrimento del valore del contenuto. Negli ambienti di progetto dove la presentazione ha la medesima importanza e
valore economico di un componente distribuibile, è bene considerare la possibilità di utilizzare una risorsa
amministrativa per il compito di presentazione.
|
|