Il software viene ridefinito tramite iterazioni nel ciclo di distribuzione software del RUP. Il ciclo di verifica trae
i propri vantaggi perché segue un approccio iterativo equivalente in questo ambiente del processo. In ogni iterazione,
il team di distribuzione software produce una o più build, ognuna delle quali diventa un potenziale candidato per la
verifica.
Il punto focale e gli obiettivi del team di sviluppo variano da un'iterazione all'altra. Quindi, i membri del team del
test devono strutturare il proprio impegno di test di conseguenza. Si consiglia di mantenere la parte di progettazione
e pianificazione di test dettagliata e anticipata al minimo e, qualora fosse necessaria, di produrre questo lavoro il
più vicino possibile al momento in cui verrà utilizzato. Si consiglia inoltre di verificare lo sviluppo di test
dettagliato e anticipato non prima dell'iterazione in anticipo.
Le aggiunte, i miglioramenti e le eliminazioni vengono eseguiti sui test implementati ed eseguiti per ogni build.
Alcuni di tali test vengono conservati e si accumulano in un corpo di test, utilizzato per build successive di verifica
regressione usate in ogni ciclo di test futuro. Questo approccio rilavora e riesamina i test durante tutto il processo,
quando viene esaminato il software stesso. Non esiste alcuna specifica software congelata, così come non esistono test
congelati. La seguente figura illustra l'evoluzione di tale situazione nel tempo.
Questo approccio iterativo, abbinato all'uso delle architetture del componente, comporta la necessità di considerare la
verifica delle regressioni nella qualità del prodotto in ogni build successiva. Ognuno dei test distribuiti
nell'iterazione X sono potenziali candidati per la verifica della regressione nell'iterazione X+1, nell'iterazione X+2
e così via. Quando il test dovrebbe essere ripetuto diverse volte, vale la pena considerare l'automazione del test.
Tale automazione fornisce un approccio alla verifica ripetuta degli scenari di utilizzo e allo staff di verifica libera
per esplorare tale verifica nelle nuove aree funzionali.
Esaminare il ciclo della verifica senza considerare il resto del progetto. La seguente figura mostra il partizionamento
dei dettagli di lavoro per la disciplina Test in un'iterazione specificata.
Questo ciclo di vita è allineato con il ciclo di iterazione seguito dal resto del team di sviluppo. L'iterazione inizia
con un'analisi da parte del team del test, che negozia con il responsabile del progetto e con altri stakeholder
(portatori d'interesse) relativamente al lavoro di verifica più utile da accettare nell'iterazione imminente. La
maggior parte dei membri del team ha un ruolo in questo impegno lavorativo.
Generalmente ogni iterazione contiene almeno un ciclo di test, come mostrato nella figura successiva. E' una pratica
abbastanza diffusa per la produzione di più build per ogni iterazione e per l'allineamento di un ciclo di test con ogni
build. Tuttavia, in alcuni casi, le build specifiche non vengono testate.
Con l'impegno di test principale in corso, una sottoserie di membri del team potrebbe esaminare nuove tecniche di
verifica. Questo impegno ha lo scopo di provare che le tecniche funzionano in modo che il team possa utilizzarle,
specialmente in iterazioni successive.
Il ciclo di verifica fa parte del ciclo di vita del software; entrambi dovrebbero iniziare in un lasso di tempo
equivalente. Il processo di progettazione e di distribuzione per i test potrebbe essere complesso e arduo come il
processo di sviluppo del prodotto software stesso. Se i test non iniziano in linea con i primi rilasci di software
eseguibili, l'impegno di test ritarderà la rilevazione di un numero eccessivo di problemi a un momento successivo nel
ciclo di sviluppo. Ciò spesso comporta un lungo periodo di correzione di bug alla fine della pianificazione di
distribuzione, impedendo il raggiungimento degli obiettivi ed eliminando i vantaggi dello sviluppo iterativo.
Sebbene le attività di definizione e pianificazione del test iniziate in precedenza possano portare alla luce errori o
difetti importanti nel lavoro di specifica iniziale, si consiglia di scegliere con cura il lavoro di verifica da
eseguire in anticipo. Oltre al potenziale per la rilavorazione già menzionato, il team del test deve prestare
attenzione alla gestione del proprio ruolo come advisor di qualità imparziali e non sviare i requisiti iniziali e le
attività di progettazione, agendo come "personale addetto al controllo della qualità". Per la loro natura, i primi
tentativi del team del progetto di comprendere il problema e gli ambiti della soluzione verranno invalidati. Si
consiglia di evitare richieste non ragionevoli sulla qualità di questo lavoro iniziale, poiché si potrebbe rischiare di
alienare il team del test dal resto del gruppo di sviluppo.
I problemi rilevati durante un'iterazione possono essere risolti all'interno della stessa iterazione o rinviati a
quella successiva; tale decisione, in ultima analisi, ha a che fare con il ruolo di responsabile del progetto. Una
delle maggiori attività per il team del test e per i responsabili del progetto è calcolare il completamento
dell'iterazione, verificando che gli obiettivi dell'iterazione, come indicato nel piano di iterazione, sono stati
raggiunti. E' presente una "rilevazione continua dei requisiti" da un'iterazione all'altra. E' qualcosa che è
necessario conoscere e sapere gestire.
La modalità di esecuzione dei test dipende da diversi fattori:
-
dal dominio dell'applicazione
-
dal budget
-
dal criterio della propria società
-
dalla tolleranza del rischio
-
dallo staff
La modalità di investimento nella verifica dipende dai criteri di valutazione della qualità e di tolleranza del rischio
nel proprio ambiente particolare.
|