Operazione: Strutturazione dell'implementazione dei test.
Questo compito descrive come definire la struttura globale dell'implementazione della suite di test.
Scopo

Lo scopo di questo compito è di:

  • Definire la struttura in cui verrà inserita l'implementazione della suite di test
  • Assegnare le responsabilità per le aree d'implementazione della suite di test ed i loro contenuti
  • Elencare le suite di test richieste
Relazioni
Passi
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.

Analisi dei requisiti di distribuzione

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.

Analisi dei requisiti di simultaneità

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.



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