Operazione: Implementazione del gruppo di test
Questo compito illustra l'identificazione dei test da eseguire insieme.
Scopo

Lo scopo di questo compito è:

  • Creare una raccolta di test da eseguire insieme per raccogliere log di test significativi
  • Permettere un'adeguata ampiezza e approfondimento della copertura del test creando delle interessanti combinazioni
Relazioni
Passi
Esame del gruppo di test candidato
Scopo:  Comprendere il gruppo di test e selezionare quale dei candidati implementare

Avviare questo compito analizzando gli elementi generali del gruppo di test, e determinare quali candidati sono adatti all'implementazione allo stato attuale. Utilizzare il piano di test di iterazione, l'elenco delle proposte di test e qualsiasi ulteriore prodotto di lavoro della definizione del test come base per la decisione.

Esame degli elementi dei test relativi e di destinazione
Scopo:  Comprensione delle relazioni tra i test pianificati e gli elementi test di destinazione

Per ciascun gruppo di test selezionato per l'implementazione, identificare gli elementi test di destinazione ed i test associati candidati per essere inclusi nell'ambito relativo.

Identificazione delle dipendenze del test
Scopo:  Identificazione di qualsiasi dipendenza del test nei confronti di altri test, ed in generale nei confronti dello stato del sistema

Considerare la configurazione dell'ambiente di test e lo specifico stato di avvio del sistema. Determinare quali requisiti di impostazione specifici vi saranno, quale l'avvio dell'insieme di dati di un database dipendente. In un ambiente in cui verrà utilizzata un'unica configurazione dell'ambiente di test per più gruppi di test, identificare qualsiasi impostazione di configurazione che possa necessitare di modifiche per ciascun gruppo di test, quali la risoluzione dello schermo oppure le impostazioni internazionali del sistema operativo.

Identificare le relazioni specifiche che intercorrono tra i test. Cercare le dipendenze in cui l'esecuzione di un test, incluso in un gruppo, genera una modifica nello stato del sistema richiesta come condizione precedente da un altro test.

Una volta identificate le dipendenze rilevanti, determinare l'esatta sequenza di esecuzione dei test.

Identificazione delle possibilità di riutilizzo
Scopo:  Migliorare la gestibilità del gruppo di test, sia riutilizzando risorse esistenti che creandone di nuove 

Una delle sfide principali nella gestione di un gruppo di test, in particolar modo uno automatico, è quella di permettere di effettuare le continue modifiche in modo semplice. È buona norma, quando possibile e se giudicato necessario, effettuare in maniera centralizzata le modifiche agli elementi utilizzati in più posti. In particolar modo quando questi sono soggetti a frequenti modifiche.

Mentre i test formano unità modulari, il loro assemblaggio all'interno di gruppi porta spesso alla creazione di elementi procedurali duplicati che possono essere gestiti in maniera più efficace se uniti. Approfittare per identificare la meccanica generale del test in modo che la si possa rifattorizzare in una routine standard per assistere nella continua manutenzione.

Applicazione dei programmi di utilità dell'infrastruttura necessari
Scopo:  Fattorizzare i dettagli delle implementazioni complesse necessarie per supportare il test come funzioni dei programmi di utilità semplificate 

Buona parte dei compiti di un test consistono nell'utilizzo di uno o più "programmi di utilità" per generare, raccogliere, diagnosticare, convertire e confrontare le informazioni raccolte durante la sua esecuzione. Questi programmi di utilità solitamente semplificano compiti complessi e laboriosi che potrebbero generare degli errori se eseguiti manualmente. Questo passo fa riferimento all'applicazione di funzioni dei programmi di utilità all'interno del gruppo di test, ed all'identificazione degli altri programmi di utilità richiesti.

È buona norma semplificare le interfacce di questi programmi di utilità, incapsulando le parti più complesse all'interno della loro implementazione privata. È inoltre consigliabile svilupparli in modo tale da poterli riutilizzare quando richiesto, sia per test manuali che automatizzati.

Conviene non nascondere le informazioni che caratterizzano un singolo test all'interno di questi programmi di utilità: al contrario, limitare le loro funzionalità ai complessi meccanismi di raccolta delle informazioni oppure al confronto del risultati effettivi con quelli previsti e dove possibile, passare le caratteristiche specifiche di un singolo test come input da e restituirle come output ad un test di controllo o ad un gruppo di test.

Determinazione dei requisiti di recupero
Scopo:  Abilitazione del recupero di un gruppo di test senza doverlo rieseguire completamente 

Determinare i punti nel gruppo di test in cui è conveniente prevedere un recupero in caso di errori in fase di esecuzione. Questa fase acquista importanza negli ambienti in cui il gruppo di test è ampio, o se questo rimarrà in esecuzione per un lungo periodo in modo non presidiato. La definizione di punti di recupero è un requisito quasi obbligatorio nei gruppi di test automatizzati, ma è altresì importante in quelli eseguiti manualmente.

In aggiunta ai punti di recupero e riavvio è possibile considerare un recupero del gruppo di test automatizzato. I due approcci al recupero automatizzato sono 1) il recupero di base, dove il gruppo di test esistente riesce a recuperare in modo autonomo da un errore secondario che si verifichi in uno dei sui test, solitamente recuperando l'esecuzione al test successivo del gruppo oppure 2) il recupero sofisticato, che ripulisce l'ambiente dopo il test in errore, ripristinando l'appropriato stato del sistema, anche riavviando il sistema operativo e ripristinando i dati se necessario. Come nel primo approccio, il gruppo di test determina il test in errore ed avvia l'esecuzione del successivo.

Implementazione dei requisiti di recupero
Scopo:  Implementazione e verifica che il processo di recupero funzioni come richiesto 

A seconda del livello di sofisticazione richiesto, sarà necessario un impegno per implementare e stabilizzare il processo di recupero. Si dovrà prevedere di dedicare del tempo alla simulazione di una serie di errori probabili (e di alcuni improbabili) per accertarsi del suo funzionamento.

In caso di recupero automatizzato, entrambi gli approcci descritti nella fase precedente hanno punti di forza e di debolezza. Considerare attentamente i costi di un recupero automatizzato sofisticato, sia in termini di sviluppo iniziale che nell'impegno di gestione a regime. A volte il recupero manuale è sufficiente.

Stabilizzazione del gruppo di test
Scopo:  Risoluzione delle dipendenze in termini di stato del sistema e di sequenza di esecuzione dei test 

È necessario dedicare tempo alla stabilizzazione del gruppo di test eseguendo dove possibile, uno o più test di prova. La difficoltà di raggiungere la stabilità aumenta in modo proporzionale con la complessità del gruppo di test, e dove vi sia una dipendenza eccessivamente stretta tra test non in relezione ed una bassa coesione tra test in relazione.

Vi è la possibilità che si verifichino degli errori durante l'esecuzione contemporanea dei test di un dato gruppo, errori che non si sarebbero presentati se i test fossero stati eseguiti separatamente. Questi sono spesso i più difficili da identificare e diagnosticare, in modo particolare se si verificano a metà dell'esecuzione di un test automatizzato. In questi casi è consigliabile eseguire nuovamente il gruppo di test ogni volta che se ne aggiungono di nuovi. Sarà così possibile ridurre il numero di test che possono potenzialmente essere la causa del problema.

Gestione delle relazioni di tracciabilità
Scopo:  Abilitazione dell'esecuzione dell'analisi di impatto e della segnalazione della valutazione sulle voci tracciate

Utilizzando i requisiti di tracciabilità evidenziati nel piano di test, aggiornare le relazioni di tracciabilità come richiesto. I gruppi di test possono essere tracciati in determinati scenari di test o proposte test. Facoltativamente, li si può tracciare in casi d'uso, elementi delle specifiche software, elementi dei modelli di implementazione o in una o più misure di completamento test.

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.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni