La verifica di accettazione è l'azione di test conclusiva 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. Esistono tre comuni strategie per
implementare un test di accettazione. Queste sono:
La strategia selezionata spesso si basa sui requisiti contrattuali, sugli standard organizzativi e aziendali e sul
dominio dell'applicazione.
La verifica di accettazione formale è un processo gestito ad alto livello e spesso si tratta di un'estensione del test
di sistema. I test vengono pianificati e progettati molto attentamente e con gli stessi dettagli della verifica di
sistema. Gli scenari del test scelti devono essere un sottoinsieme di quelli eseguiti nel test di sistema. E'
importante non deviare in alcun modo dagli scenari di test scelti. In molte organizzazioni la verifica di accettazione
formale viene completamente automatizzata.
Le attività ed i prodotti di lavoro sono gli stessi della verifica di sistema. In alcune organizzazioni ad eseguire il
test di accettazione è il settore dello sviluppo (o il relativo gruppo indipendente di test), con dei rappresentanti
del settore degli utenti finali. In altre organizzazioni la verifica di accettazione viene eseguita completamente dal
settore dell'utente finale o da un gruppo obiettivo di persone scelte dall'organizzazione dell'utente finale.
I vantaggi di questa forma di verifica sono:
-
Le funzioni e le caratteristiche da testare sono note.
-
I dettagli dei test sono noti e possono essere misurati.
-
I test possono essere automatizzati, cosa che consente la verifica di regresso.
-
L'andamento dei test può essere misurato e monitorato.
-
I criteri di accettabilità sono noti.
Gli svantaggi comprendono:
-
Richiesta di notevoli risorse e pianificazione.
-
I test possono essere una ulteriore implementazione dei test di sistema.
-
La verifica potrebbe non rilevare i difetti soggettivi del software, poiché si cercano solo i difetti che ci si
aspetta di trovare.
Nella verifica di accettazione informale le procedure per l'esecuzione del test non sono definite in modo altrettanto
rigoroso quanto quelle della verifica di accettazione formale. Le funzioni e le attività di business da esaminare
vengono identificate e documentate ma non esistono dei particolari scenari di test da seguire. Il singolo tester decide
cosa fare. Questo approccio alla verifica di accettazione non è controllato quanto una verifica formale ed è
maggiormente soggettivo rispetto a quest'ultima.
La verifica di accettazione informale viene eseguita più frequentemente dall'organizzazione degli utenti finali.
I vantaggi di questa forma di verifica sono:
-
Le funzioni e le caratteristiche da testare sono note.
-
L'andamento dei test può essere misurato e monitorato.
-
I criteri di accettabilità sono noti.
-
Viene rilevato un maggior numero di difetti soggettivi, rispetto alla verifica di accettazione formale.
Gli svantaggi comprendono:
-
Sono richieste delle risorse, una pianificazione e delle risorse di gestione.
-
Non si ha il controllo sugli scenari di test utilizzati.
-
Gli utenti potrebbero conformarsi al tipo di funzionamento del sistema e non individuarne i difetti.
-
Gli utenti potrebbero focalizzare l'attenzione sul confronto fra il nuovo e il vecchio sistema, piuttosto che
cercare dei difetti.
-
Le risorse per la verifica di accettazione non sono sotto il controllo del progetto e potrebbero non essere
vincolate.
La verifica Beta è la meno controllata fra le tre strategie di test di accettazione. Nella fase di verifica beta la
quantità di dettagli, i dati e l'approccio utilizzato sono a completa discrezione del singolo tester. Ogni tester è
responsabile della creazione del proprio ambiente, della selezione dei propri dati e della scelta delle funzioni, delle
caratteristiche o delle attività da esaminare. Ogni tester è responsabile della scelta di criteri propri per
l'accettazione o meno del sistema nel suo stato corrente.
La verifica beta viene implementata dagli utenti, spesso con poca o nessuna gestione da parte del settore di sviluppo
(o di altra organizzazione diversa da quella dell'utente finale). La verifica beta è la più soggettiva fra tutte le
strategie di test di accettazione.
I vantaggi di questa forma di verifica sono:
-
La verifica viene implementata dagli utenti.
-
Sono disponibili dei grossi volumi di potenziali risorse di test.
-
Aumenta la 'customer satisfaction' (soddisfazione del cliente) nei partecipanti.
-
Si rilevano più difetti soggettivi rispetto alla verifica di accettazione formale o quella informale.
Gli svantaggi comprendono:
-
Potrebbero non essere testate tutte le funzioni o caratteristiche.
-
E' difficile misurare l'andamento del test.
-
Gli utenti potrebbero conformarsi al tipo di funzionamento del sistema e non individuare o segnalare i difetti.
-
Gli utenti potrebbero focalizzare l'attenzione sul confronto fra il nuovo e il vecchio sistema, piuttosto che
cercarne i difetti.
-
Le risorse per la verifica di accettazione non sono sotto il controllo del progetto e potrebbero non essere
vincolate.
-
I criteri di accettabilità non sono noti.
-
Sono necessarie maggiori risorse di supporto per la gestione dei tester della versione beta.
|