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:
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.
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.
|
|