La verifica viene applicata a differenti tipi di destinazioni, in differenti fasi o livelli di impegno lavorativo. Tali
livelli vengono distinti generalmente dai ruoli con maggiore esperienza in assoluto per progettare e condurre i test e
in cui le tecniche sono più appropriate per la verifica a ogni livello. E' importante verificare che venga mantenuto un
certo equilibrio in questi impegni lavorativi differenti.
Verifica dello sviluppatore
La verifica dello sviluppatore denota gli aspetti della progettazione test e dell'implementazione più appropriati per
essere intrapresi dal team di sviluppatori. Tale verifica è antitetica rispetto alla verifica indipendente. Nella
maggior parte dei casi, l'esecuzione del test avviene inizialmente con il gruppo di verifica dello sviluppatore che ha
progettato e implementato il test, ma è consigliabile che gli sviluppatori creino i propri test in modo da renderli
disponibili per l'esecuzione da parte dei gruppi di verifica indipendenti.
Tradizionalmente, la verifica dello sviluppatore è stata considerata di più rispetto alla verifica dell'unità. Sebbene
alcuni sviluppatori eseguano anche la verifica dell'integrazione di livelli variabili, questa dipende dalla cultura e
da altre questioni contestuali. Si consiglia di fare in modo che la verifica dello sviluppatore vada oltre la semplice
verifica di unità indipendenti in isolamento.
Verifica indipendente
La verifica indipendente denota la progettazione e l'implementazione del test eseguite in modo più appropriato da una
persona indipendente dal team di sviluppatori. E' possibile considerare questa distinzione come un superinsieme, che
include Verifica indipendente & Convalida. Nella maggior parte dei casi, l'esecuzione del test avviene inizialmente
con il gruppo di verifica indipendente che ha progettato e implementato il test, ma i tester indipendenti dovrebbero
creare i propri test in modo da renderli disponibili per l'esecuzione da parte dei gruppi di verifica dello
sviluppatore. Boris Beizer fornisce la seguente spiegazione della differenza di obiettivo tra la verifica indipendente
e la verifica dello sviluppatore:
"Lo scopo della verifica indipendente è fornire una prospettiva differente e, quindi, differenti test; per di più,
per condurre tali test in un ambiente più ricco [...] rispetto a quello possibile per uno sviluppatore." [BEI95]
Verifica di stakeholder indipendente
Una vista alternativa della verifica indipendente è che rappresenta la verifica basata sulle esigenze e sulle
problematiche di vari stakeholder (portatori d'interesse). Viene quindi indicata come Verifica di stakeholder. Questa è
una distinzione importante, che include una serie di problematiche di stakeholder più ampia rispetto a quella
tradizionale, estendendo il senso del generico "cliente" con gli stakeholder come ad esempio lo staff di supporto
tecnico, i technical trainer, il personale delle vendite oltre a clienti e utenti.
Come commento finale, la nozione di XP dei test dei clienti è correlata alla suddivisione in categorie
della verifica indipendente nel RUP.
Verifica dell'unità
La verifica dell'unità è incentrata sulla verifica dei più piccoli elementi testabili del software. Generalmente, la
verifica dell'unità si applica ai componenti rappresentati nel modello di implementazione per verificare che i flussi
di dati e di controllo siano stati esaminati e che funzionino nel modo previsto. L'Implementatore esegue una verifica
dell'unità man mano che l'unità viene sviluppata. I dettagli della verifica dell'unità sono descritti nella disciplina
Implementazione.
Verifica dell'integrazione
La verifica dell'integrazione viene eseguita per accertarsi che i componenti nel modello di implementazione funzionino
correttamente quando vengono combinati per eseguire un caso d'uso. L'obiettivo del test è un pacchetto o un insieme di
pacchetti nel modello di implementazione. Spesso i pacchetti combinati provengono da differenti organizzazioni di
sviluppo. La verifica dell'integrazione espone l'incompletezza o gli errori nelle specifiche dell'interfaccia del
pacchetto.
In alcuni casi, gli sviluppatori presuppongono che altri gruppi, ad esempio i tester indipendenti, eseguano i test di
integrazione. Questa situazione presenta dei rischi sia per il progetto software che per la qualità software perché:
-
le aree di integrazione sono un punto comune di errori del software.
-
i test di integrazione eseguiti da tester indipendenti generalmente utilizzano delle tecniche black-box e trattano
componenti software di dimensioni maggiori.
Un approccio migliore è considerare la verifica dell'integrazione come responsabilità sia dei tester indipendenti che
dello sviluppatore, ma fare in modo che la strategia di impegno della verifica di ogni team non si sovrapponga in modo
significativo. La natura esatta di tale sovrapposizione si basa sulle esigenze del singolo progetto. Si consiglia di
promuovere un ambiente in cui gli sviluppatori e i tester di sistema indipendenti condividano una singola visione di
qualità. Consultare Concetto:
Verifica dello sviluppatore per ulteriori informazioni.
Verifica del sistema
Tradizionalmente, la verifica del sistema viene eseguita quando il software funziona come un'entità unica. Un ciclo di
vite iterativo consente che la verifica del sistema avvenga molto prima, non appena vengono implementati i sottoinsiemi
ben formati della funzionalità del caso d'uso. Generalmente l'obiettivo è costituito dagli elementi di funzionamento
end-to-end del sistema.
Verifica di accettazione
La verifica di accettazione dell'utente è l'azione di test conclusiva eseguita prima della distribuzione del
software. L'obiettivo della verifica di accettazione è di controllare che il software sia pronto e possa essere
utilizzato dagli utenti per eseguire le funzioni e le attività per le quali è stato creato il software. Consultare Concetto: Verifica di accettazione per ulteriori informazioni.
Esistono altre nozioni della verifica di accettazione, generalmente caratterizzate da un hand-off proveniente da un
gruppo o da un team a un altro. Ad esempio, una verifica di accettazione build è la verifica effettuata per
accettare l'hand-over di una nuova build del software dalla distribuzione nella verifica indipendente.
Un commento relativo alla sequenza e alla tempificazione dei livelli di test
Tradizionalmente, l'implementazione della verifica dell'unità avviene nell'interazione ed è considerata come prima fase
della verifica: è richiesto che tutte le unità superino la verifica prima di condurre fasi successive. Tuttavia, in un
processo di sviluppo iterativo, questo approccio è una regola generale, inappropriata. Un approccio migliore è
identificare i test dell'unità, di integrazione e del sistema che offrono un maggiore potenziale per la rilevazione
degli errori, quindi implementarli ed eseguirli in base a una combinazione dei rischi maggiori e dell'ambiente di
supporto.
|