Concetto: Il ciclo della verifica
Questa linea guida descrive in che modo la disciplina di verifica si adatta all'interno del ciclo di vita del RUP.
Relazioni
Elementi correlati
Descrizione principale

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.

Diagramma dei componenti di iterazione e di test

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.

Diagramma dei componenti di iterazione e di test

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.

Diagramma di un'iterazione nel tempo

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.