Operazione: Identify Testability Mechanisms
In questa attività viene descritto come identificare i meccanismi generali della soluzione tecnica necessari per agevolare l'approccio di test e come descrivere lo scopo generale e le caratteristiche principali di questi meccanismi.
Relazioni
Passi
Esaminare l'architettura del software e i relativi ambienti di destinazione
Scopo:  Acquisire la conoscenza dell'architettura del software e delle sue relazioni con gli ambienti di distribuzione di destinazione. 

Per eseguire tale attività all'interno del contesto appropriato, è importante disporre di una buona conoscenza del software da sviluppare, della relativa architettura e dei meccanismi e caratteristiche chiave che lo supporteranno. Esaminare la documentazione disponibile per l'architettura del software per acquisire una conoscenza iniziale e integrarla con colloqui e discussioni con l'architetto del software, se necessario. Considerare l'impatto che potrebbe avere ogni ambiente di distribuzione di destinazione su queste informazioni e prendere nota delle conclusioni importanti che si ritengono rilevanti per l'impegno di test.

Identificazione dei meccanismi candidati per il test
Scopo:  Identificare i meccanismi di test potenziali che verranno richiesti dall'approccio di verifica. 

Utilizzando la conoscenza dell'architettura software e dei relativi ambienti di destinazione, esaminare le informazioni fornite nell'approccio di test. Considerare gli aspetti tecnici fondamentali dell'approccio e stilare un elenco dei meccanismi candidati che saranno necessari per il suo supporto. Ecco un elenco parziale dei meccanismi comuni che si devono considerare come candidati: persistenza, concorrenza, distribuzione, comunicazione, protezione, gestione transazione, ricupero, gestione & creazione report di rilevamento di errori, controllo & sincronizzazione di processo.

Questi meccanismi spesso si applicano sia all'impegno di test manuale che automatizzato, benché un meccanismo possa avere più o meno importanza per la verifica manuale o automatizzata. Inoltre, laddove lo stesso meccanismo richiede l'impegno di test sia manuale che automatizzato, le caratteristiche della soluzione implementata sono di solito diverse.

Inventario dei meccanismi di test esistenti
Scopo:  Identificare le opportunità di riutilizzare le implementazioni esistenti per i meccanismi candidati e identificare quali implementazioni aggiuntive dovranno essere sviluppate. 

Esaminare i tool di test disponibili e le implementazioni di test esistenti, quindi creare un inventario dei meccanismi che dispongono di una o più soluzioni esistenti. Sebbene questa fase sia in modo ovvio più importante per l'impegno di test automatizzato, esistono considerazioni equivalenti per l'impegno di test manuale.

Argomenti secondari:

Meccanismi di automazione di test Inizio pagina

Iniziare compilando un elenco di tool disponibili o che si pianifica di acquistare. Ricordarsi che i tool di automazione richiedono molti moduli e l'elenco comprenderà di solito più tool di implementazione di test automatizzata e di esecuzione. Per ogni tool, esaminare i meccanismi che fornisce. Ad esempio, il tool di creazione di script che si intende utilizzare, fornisce un meccanismo proprio di persistenza di dati e, in tal caso, è appropriato per le proprie esigenze oppure occorre integrarlo? Altre domande possono essere: il tool di esecuzione consente l'esecuzione simultanea di script di test su più macchine client host? Il tool di esecuzione, consente la distribuzione degli script da una macchina principale centrale a più macchine client host?

Laddove sono disponibili le implementazioni di automazione di test esistenti, ci saranno ulteriori meccanismi da inventariare. Alcuni aspetti di queste implementazioni estenderanno o integreranno i meccanismi di base forniti dai tool per renderli più utili. Altri aspetti offriranno implementazioni per meccanismi aggiuntivi non forniti nel tool di base.

Meccanismi di test manuale Inizio pagina

A un livello base, ciò riguarda la revisione delle linee guida del test che esistono per l'implementazione e l'esecuzione del test. Occorre cercare soluzioni di processo esistenti per i problemi quali la simultaneità, come i tester possono condividere insiemi di dati, soprattutto banchi di dati esistenti senza ostacolarsi tra di loro; la distribuzione, se il team di test viene distribuito, quali soluzioni sono disponibili per coordinare impegni di test separati.

Definizione dei meccanismi di test che si utilizzeranno
Scopo:  Comunicare le decisioni sui meccanismi di test richiesti. 

Dopo aver preso una decisione sui meccanismi di test richiesti, occorre comunicare le proprie scelte al team di test e agli altri stakeholder dell'impegno di test. Si consiglia di documentare le decisioni sui meccanismi di test richiesti per l'automatizzazione come parte della documentazione dell'architettura di automazione di test e quelle relative alla verifica manuale come parte delle linee guida del test.

In alternativa alla documentazione formale, si potrebbe scegliere di registrare semplicemente tali informazioni come un insieme di note architetturali informali e di processo, accompagnate da alcuni diagrammi esplicativi e possibilmente conservate su una lavagna bianca. Durante l'esecuzione e l'implementazione del test, i singoli tester utilizzeranno tali informazioni per prendere decisioni tattiche.

Laddove è stato identificato il requisito potenziale per le interfacce di test speciali che dovranno essere integrate nel software da sviluppare, occorre considerare di registrare tale requisito creando una o più descrizioni di specifiche di interfaccia di test; questa descrizione deve fornire un nome, una breve descrizione ed elencare i requisiti o le caratteristiche principali dell'interfaccia di test. Evitare di perdere molto tempo su tali descrizioni; l'elenco dei requisiti e delle caratteristiche verrà successivamente dettagliato in Attività: Definizione elementi di verificabilità.

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