Impostazione dell'ambiente di test su uno stato noto
Scopo:
|
Per stabilire esattamente l'ambiente di test in preparazione dell'esecuzione della suite di test.
|
Impostare l'ambiente di test per essere certi che tutti i componenti richiesti (hardware, software, tool, dati, ecc.)
siano stati determinati, disponibili e pronti per l'ambiente di prova nello stato corretto per condurre i test. Di
solito ciò riguarderà qualche forma di reimpostazione dell'ambiente base (ad esempio, il registro e altri file di
configurazione), il ripristino di database sottostanti allo stato richiesto e l'impostazione di una qualsiasi
periferica (ad esempio, il caricamento della carta nelle stampanti). Mentre alcune attività possono essere eseguite in
modo automatico, alcuni aspetti richiedono tuttavia l'intervento umano.
L'utilizzo di tool di supporto dell'ambiente come quelli che abilitano la cattura e il ripristino di immagini sul disco
fisso sono estremamente utili per gestire efficacemente questo impegno.
|
Impostazione delle opzioni dei tool di esecuzione
Scopo:
|
Per configurare correttamente i tool utilizzati nell'esecuzione della suite di test.
|
Impostare le opzioni di esecuzione dei tool di supporto. A seconda della complessità del tool, è possibile che vi siano
molte opzioni da considerare. La non corretta impostazione di queste opzioni potrebbe ridurre l'utilità e il valore dei
file log di test e degli altri output risultanti. Quando possibile, memorizzare le opzioni dei tool e le impostazioni
in modo che possano essere facilmente ricaricate sulla base di uno o più profili predeterminati. Nel caso dei tool di
esecuzione dei test automatici, occorre considerare molte impostazioni, come la velocità di esecuzione.
Nel caso di test manuale, spesso è semplicemente una questione di collegamento ai sistemi di controllo delle richieste
di modifica e delle problematiche oppure di partizione di una nuova immissione univoca in un sistema di supporto per la
registrazione dei risultati. Occorre prendere in considerazione alcuni elementi come il nome, l'ubicazione e lo stato
del log di test in cui scrivere.
|
Pianificazione dell'esecuzione della suite di test
Scopo:
|
Per determinare l'ora appropriata d'inizio dell'esecuzione del test.
|
In molti casi dove è possibile partecipare all'esecuzione del test, la suite di test può essere eseguita relativamente
on demand (su richiesta). In questi casi, la pianificazione necessiterà probabilmente di tenere conto di alcune
valutazioni come il lavoro di altri tester, di altri membri di team così come di diversi team di test che condividono
l'ambiente di test. In questi casi, l'esecuzione del test necessiterà tipicamente di soluzioni temporanee per
infrequenti reimpostazioni dell'ambiente.
Tuttavia, in casi dove è richiesta l'esecuzione non presidiata di test automatici oppure è necessario coordinare
l'esecuzione di molti test in esecuzione simultaneamente su macchine diverse, potrebbe essere necessario avere qualche
forma di meccanismo di pianificazione automatizzato. Utilizzare le funzioni del proprio tool di esecuzione dei test
automatizzato oppure sviluppare le proprie funzioni del programma di utilità per attivare la pianificazione richiesta.
|
Esecuzione della suite di test
Scopo:
|
Per condurre i test racchiusi nella suite di test e per controllarne il completamento.
|
L'esecuzione della suite di test varierà a seconda che il test venga condotto automaticamente o manualmente. In
entrambi i casi, le suite di test sviluppate durante le attività di implementazione del test sono utilizzate per
eseguire automaticamente i test o per guidare l'esecuzione manuale dei test.
|
Valutazione dell'esecuzione della suite di test
Scopo:
|
Per stabilire se l'esecuzione della suite di test sia stata completata oppure terminata in modo anomalo e
per effettuare una valutazione riguardante l'azione correttiva richiesta.
|
L'esecuzione del test viene completata o terminata in una delle seguenti condizioni:
-
Normale: tutti i test vengono eseguiti come pianificati al completamento.
-
Anomalo o prematuro: i test non sono stati eseguiti completamente come pianificati. Quando i testi terminano in
modo anomalo, i log dei test da cui derivano i risultati successivi potrebbero non essere affidabili. E' necessario
individuare la causa per cui i test terminano in modo anomalo e, se necessario, correggere l'errore e rieseguire i
test.
|
Ripristino di test arrestati
Scopo:
|
Per determinare l'azione correttiva appropriata, al fine di ripristinare l'esecuzione della suite di test
arrestata e, se richiesto, correggere il problema e ripristinare e rieseguire la suite di test.
|
Per ripristinare i test arrestati, effettuare quanto segue:
Esaminare i log di test e gli altri output per completezza e accuratezza. Individuare dove si sono verificati gli
errori ed esaminarli.
Quando viene impiegata l'automazione nei test, esistono due categorie di test arrestati che occorre conoscere:
-
Errori gravi-il sistema dà errore (errori di rete, interruzioni hardware, ecc.)
-
Malfunzionamenti del test-qualche parte di un test all'interno della suite non può essere eseguita come
pianificata.
Quando si verifica una qualsiasi categoria di funzionalità anomala durante l'esecuzione del test, si possono avere i
seguenti sintomi:
-
si verifica un elevato numero di (ricorrenza progressiva) azioni o finestre non previste mentre viene eseguita la
suite di test
-
l'ambiente di test appare privo di reazioni, lento o in uno stato non desiderato (come bloccato o interrotto).
Esaminare i sintomi fino a quando non viene determinata la causa principale del problema.
Gli errori possono essere trovati nei dati di input utilizzati dal test, dal test stesso o da altri aspetti del test
come l'ambiente o le impostazioni del tool di runtime. E' frequente che la correzione di un errore in una fase di test
richieda la presenza del corretto stato in tutte le altre fasi di test.
Una volta terminata la verifica dei problemi, è possibile correggere gli eventuali errori individuati. Per effettuare
correzioni permanenti all'ambiente, ai dati del test o al test stesso, è una buona prassi ripristinare nuovamente ogni
aspetto del test a uno stato noto prima di applicare una qualsiasi correzione permanente. Ciò garantisce che nessuna
modifica indesiderata o non valida aggiuntiva possa trovare la via nell'ambiente di stato conosciuto.
Dopo aver effettuato le modifiche necessarie, salvare il test ed eseguire un backup dei dati di input di
accompagnamento e dell'ambiente di test
Pianificare ed eseguire nuovamente la suite di test. A seconda del processo di ripristino disponibile, sarà possibile
riavviare la suite di test da un punto provvisorio piuttosto che iniziando dal principio. Si noti che per abilitare il
ripristino dell'esecuzione del test da un punto di partenza che lo attraversa, si richiedono l'implementazione e la
manutenzione progressiva di qualche forma di procedura di ripristino parziale.
Confermare l'esecuzione fino al completamento della suite di test. Se permangono ancora dei problemi, utilizzare queste
sezioni secondarie che descrivono il ripristino di test arrestati fino a quando non vengono risolti tutti i problemi.
|
Controllo dei log di test per la completezza ed esattezza
Scopo:
|
Per determinare se l'esecuzione della suite di test ha generato delle informazioni di test utili e in caso
contrario, per identificare le opportune azioni correttive.
|
Quando l'esecuzione del test si completa inizialmente, i log di test devono essere revisionati per garantirne
l'affidabilità e che gli errori notificati, le avvertenza o i risultati non previsti non siano stati causati da
influenze esterne (la finalità del test), come l'impostazione errata dell'ambiente oppure i dati di input non validi
per il test.
Per test automatizzati condotti mediante GUI, gli errori di test più comuni comprendono:
-
Errori di verifica del test-ciò si verifica quando il risultato effettivo e il risultato previsto non
corrispondono. Accertarsi che i metodi di verifica utilizzati siano concentrati soltanto sugli elementi essenziali
e/o sulle proprietà ed effettuare le modifiche se necessario.
-
Finestre GUI non previste-ciò accade per diversi motivi. Il motivo più frequente è quando una finestra GUI
diversa da quella prevista è attiva oppure il numero di finestre GUI visualizzate è maggiore di quello previsto.
Accertarsi che l'ambiente di test sia stato impostato e inizializzato come richiesto per una corretta esecuzione
del test.
-
Finestre GUI mancanti-questo errore viene rilevato quando non è disponibile una finestra GUI di cui si
prevedeva la disponibilità (ma non necessariamente attiva). Accertarsi che l'ambiente di test sia stato impostato e
inizializzato come richiesto per una corretta esecuzione del test. Accertarsi che le effettive finestre mancanti
siano (stati) rimossi dalla finalità del test.
Se gli errori riportati sono dovuti a malfunzionamenti del prodotto di lavoro sottoposto a verifica o a problemi
nell'ambiente di test, prendere le azioni correttive adeguate e rieseguire il test.
Se il log del test consente di determinare che gli errori sono dovuti ad errori autentici negli elementi test di
destinazione, la parte di esecuzione dell'attività è completa.
|
Ripristino dell'ambiente di test ad uno stato noto
Scopo:
|
Per essere certi che l'ambiente sia correttamente reimpostato dopo l'esecuzione della suite di test.
|
(Vedere la prima fase) Occorre successivamente ripristinare l'ambiente allo stato originale. Di solito ciò riguarderà
qualche forma di reimpostazione dell'ambiente base (ad esempio, il registro e altri file di configurazione), il
ripristino di database sottostanti allo stato conosciuto e in aggiunta alle attività come il caricamento della carta
nelle stampanti. Mentre alcune attività possono essere eseguite in modo automatico, alcuni aspetti richiedono tuttavia
l'intervento umano.
|
Gestione delle relazioni di tracciabilità
Scopo:
|
Per abilitare l'esecuzione dell'analisi di impatto e della segnalazione della valutazione sulle voci
tracciate.
|
Utilizzando i requisiti di tracciabilità descritti nel piano del test, aggiornare le relazioni di tracciabilità come
richiesto. Un buon punto di partenza è considerare la tracciabilità in termini di misurazione del grado di esecuzione o
completamento del test. Come regola generale, si consiglia di basare la misurazione del grado di esecuzione del test
rispetto alle motivazioni scoperte durante le attività di pianificazione del test.
E' inoltre possibile tenere traccia delle suite di test rispetto agli scenari di test definiti che realizzano.
L'esecuzione della traccia può avvenire anche rispetto agli elementi dei requisiti, della specifica software, della
progettazione o dell'implementazione.
Qualsiasi relazione è stata scelta come importante per la traccia, sarà necessario aggiornare lo stato delle relazioni
che sono state stabilite durante l'implementazione della suite di test.
|
Valutazione e verifica dei risultati
Scopo:
|
Per verificare che l'attività sia stata completata correttamente 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.
Chiedere alle persone, che effettuano le attività a valle e che dipendono dal proprio lavoro come input, di prendere
parte alla revisione del proprio lavoro provvisorio. E' opportuno fare ciò quando si ha ancora del tempo disponibile
per avviare dei correttivi legati alle loro considerazioni. Inoltre, è necessario valutare il lavoro svolto rispetto ai
prodotti di lavoro di input chiave per accertarsi che vengano rappresentati in modo accurato e sufficiente. Potrebbe
essere utile su questa base fare revisionare il proprio lavoro all'autore del prodotto di lavoro di input.
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.
|
|