Controllo delle motivazioni e degli elementi del test
Scopo:
|
Per determinare l'influenza sulla missione, sulle motivazioni e sugli elementi di test nell'approcciare il
prossimo impegno di test.
|
Utilizzando come contesto la missione di valutazione, verificare il piano di test dell'iterazione ed esaminare le
motivazioni che sono state identificate per il prossimo impegno di test. Potrebbe essere necessario effettuare
ulteriori verifiche sulla fonte delle motivazioni - di solito il piano di iterazione fornisce un modo per individuare
le informazioni aggiuntive.
Per ciascuna motivazione, occorre stabilire l'approccio test e le relative tecniche richieste. Inoltre, verificare il
piano del test di iterazione ed esaminare gli elementi del test. Ciascun elemento test di destinazione deve essere
considerato in relazione ad ogni motivazione e l'approccio e le tecniche estesi conseguentemente. Se non si è in grado
di individuare maggiori dettagli o non si ha dimestichezza con gli elementi del test, potrebbe essere utile discutere
gli elementi di destinazione con il personale di sviluppo, iniziando solitamente con l'architetto di software o con i
responsabili del team di sviluppo.
Concentrare l'attenzione sull'identificazione della minima serie di tecniche necessaria per affrontare
soddisfacentemente la missione di valutazione e le motivazioni. Ricercare le opportunità dove è possibile utilizzare
una tecnica per affrontare più di un aspetto della verifica richiesta. Prendere nota di altre potenziali tecniche che
sembrano interessanti da esaminare, essendo comunque capace di identificarle come aggiuntivi piuttosto che essenziali.
|
Controllo dell'architettura software
Scopo:
|
Per considerare l'influenza dell'architettura software sull'approccio di test.
|
Analizzare l'architettura software per acquisire una conoscenza degli elementi-meccanismi chiave, le principali viste e
così via. Di solito il documento dell'architettura software fornisce delle ottime informazioni orientate al giusto
livello di dettaglio per l'uso nel considerare una strategia di test. Per una giusta interpretazione delle informazioni
o in assenza di un documento, è utile discutere l'architettura con il personale di sviluppo, di solito parlando
direttamente con l'architetto di software o con uno dei responsabili del team di sviluppo.
Concentrare l'attenzione sull'identificazione e discussione dei meccanismi chiave e sull'acquisizione di una buona
conoscenza di questi aspetti del sistema. Ciascun meccanismo e funzione chiave dell'architettura presenterà
probabilmente delle sfide e dei vincoli per l'impegno del test. Ad esempio, un'architettura distribuita può richiedere
di organizzare il team del test in team secondari, con ciascun team destinato ad un livello strutturale.
Mentre un modo creativo per verificare la strategia di implementazione & esecuzione può spesso essere utilizzato
per superare queste sfide, si rende necessario al team di sviluppo modificare il software per attivare l'esecuzione del
test come discusso nella sezione Compito: Definizione degli elementi di verificabilità.
|
Considerazioni sulle ampie valutazioni di approccio al test
Scopo:
|
Per considerare la completezza dell'approccio di test in termini di ampiezza e profondità.
|
Considerando tutti i dettagli ora conosciuti sui requisiti dell'approccio del test, è opportuno fare un passo indietro
e considerare l'approccio del test da una prospettiva di livello più alto. Quali sono gli elementi che l'approccio del
test dovrebbe evidenziare ma non evidenzia? Ci sono delle considerazioni da approfondire che non appaiono in alcuna
delle informazioni documentate?
In base all'esperienza acquisita, revisionare i requisiti per l'approccio del test al fine di ampliare il proprio
controllo in questa fase del ciclo di vita del progetto. E' necessario considerare dei requisiti aggiuntivi che
aiuteranno a presentare un approccio più completo.
|
Identificazione delle tecniche di test esistenti per il riutilizzo
Scopo:
|
Per riutilizzare o adattare le tecniche di test collaudate esistenti, dove appropriato.
|
In base alla propria esperienza o di altre pratiche acquisite, identificare le tecniche esistenti che soddisferanno i
requisiti dell'approccio al test oppure che possono essere adottate per soddisfarli.
|
Identificazione di tecniche aggiuntive
Scopo:
|
Per identificare le tecniche richieste per fornire un approccio al test completo e sufficiente.
|
Non è tremendamente utile pensare in termini di approccio test "completo" - esistono sempre delle tecniche aggiuntive
che si possono provare se solo si avessero tempi e risorse illimitate.
Tuttavia, è importante che l'approccio al test sia abbastanza completo ed esauriente per consentire una valutazione
utile della qualità percepita. Ciò richiede un approccio che valuti sufficienti aspetti del rischio qualità o delle
dimensioni di qualità per il team del progetto al fine di valutare la qualità percepita con un livello di confidenza
giustificato.
|
Definizione delle tecniche
Scopo:
|
Per descrivere le attività di ciascuna tecnica, incluso l'obiettivo della verifica che supporta.
|
Descrivere le attività di ciascuna tecnica. Indicare il tipo di verifica che supporta, l'obiettivo e lo scopo, il
metodo di implementazione e di valutazione e le necessità di automazione della tecnica.
In molti casi verranno riutilizzate le tecniche da un progetto all'altro. In questa situazione è possibile
semplicemente fare riferimento ad una comune definizione della tecnica o copiare la definizione esistente e
controllarla opportunamente.
Per ciascuna tecnica esistente o richiesta:
Molte tecniche supporteranno più di un tipo di verifica, pertanto occorre prestare attenzione nell'identificare quali
test la tecnica dovrà supportare. Ciò aiuta ad identificare l'obiettivo dell'impegno richiesto se la tecnica viene
definita per la prima volta.
Riflettere sull'obiettivo e sul valore sottostanti che questa tecnica rappresenta.
Definire in che modo verrà implementata la tecnica. Non è sufficiente semplicemente affermare "Si stanno verificando le
prestazioni del sistema"-occorre seriamente considerare in che modo è possibile completare questa operazione.
Alcune tecniche che si intendono utilizzare non saranno economiche da perseguire. Mediante una breve descrizione su
come si intende accostarsi all'implementazione di questa tecnica, sarà possibile avere un quadro completo della
logistica interessata e della praticità di perseguire più avanti questa tecnica.
Stabilire in che modo si osserveranno e valuteranno i risultati di ciascun test implementato utilizzando questa
tecnica. Considerare le diverse previsioni di test che sono disponibili - esiste un'unica previsione o vi
sono modi diversi per determinare il risultato di ciascun test?
L'automazione può giocare un ruolo importante in molte tecniche di test. In alcuni casi sarà meno complessa, fornendo
semplicemente un supporto per la conduzione dei test manuali.
Riflettere in che modo il lavoro che utilizza questa tecnica può essere efficacemente implementato, sostenuto e
gestito. Occorre essere di ampie vedute, considerando quante più opzioni possibili.
Identificare i tool appropriati da utilizzare con questa tecnica di test. Utilizzare il lavoro della fase successiva
che ha identificato gli impieghi dell'automazione.
Ricordarsi di considerare una vasta gamma di categorie di tool; il proprio elenco di tool candidati deve includere più
tool di quelli solo per l'automazione di esecuzione del test. Oltre ai tool che automatizzano l'esecuzione del test,
utilizzare i tool che miglioreranno la produttività del team di test riducendo le attività ripetitive e laboriose, come
i tool per la gestione dei dati del test, l'analisi dei risultati e la notifica degli errori e delle richieste di
modifica, ecc.
|
Descrizione dell'architettura di automazione test
Scopo:
|
Per definire un'architettura candidata per il sistema di automazione del test.
|
Sulla base dell'esperienza acquisita in sistemi analoghi o in simili domini di problemi, definire un'architettura
candidata per il sistema di automazione del test.
È consigliato il controllo delle informazioni relative allo sviluppo dell'architettura software per ricevere assistenza
su questa attività.
|
Definizione della strategia per la gestione della configurazione della risorsa del test
Scopo:
|
Per identificare i requisiti che il test avrà per la gestione della configurazione.
|
Come molti altri prodotti di lavoro realizzati durante un progetto di sviluppo software, le risorse del test sono
candidate per la gestione della configurazione e il controllo della versione.
I requisiti specifici possono essere complessi, con la decisione di utilizzare dei servizi di recupero e di backup
basilari abilitati, oppure di pieno supporto per lo sviluppo parallelo di script di test automatizzati in più siti
rispetto a diverse versioni di un'applicazione.
Delineare i propri requisiti per la gestione della configurazione e descrivere le necessità logistiche probabili per
realizzare quei requisiti.
|
Valutazione della disponibilità delle risorse riutilizzabili
Scopo:
|
Per ridurre il rischio e l'impegno riutilizzando le risorse sperimentate esistenti.
|
A volte può avere senso realizzare delle nuove risorse e altre volte non lo ha. Stabilire un buon equilibrio tra una
propria filosofia "autonoma" e un rigido e burocratico criterio di creazione di un nuovo prodotto di lavoro.
Può verificarsi che in determinati casi un approccio sia migliore di un altro; occorre essere sufficientemente
flessibili per trarre vantaggio dai benefici che entrambi gli approcci apportano.
|
Cattura dei risultati
Scopo:
|
Per registrare informazioni importanti sull'approccio del test.
|
Subordinato da un numero di fattori, inclusi la dimensione del team e la cultura dell'organizzazione, ci saranno
modalità migliori e peggiori per registrare le proprie decisioni sull'approccio del test.
Si avranno tipicamente due tipi di audience da considerare: il team di gestione intenderà revisionare queste
informazioni per fornire un'approvazione ed essere al corrente di implicazioni logistiche dell'approccio e il team del
test che intenderà utilizzare l'approccio come guida per il lavoro da intraprendere. Individuare un mezzo appropriato
per affrontare entrambe le esigenze: probabilmente utilizzando un sito web Intranet del progetto.
|
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.
|
|