La disciplina del test agisce da provider di servizi per le altre discipline sotto molti aspetti. Il test è incentrato
principalmente sulla valutazione della Qualità del
prodotto, realizzata mediante le seguenti procedure di base:
-
Ricerca e documentazione degli errori nella qualità del software.
-
Segnalazione sulla qualità del software percepita.
-
Convalida e prova delle assunzioni fatte in fase di progettazione e delle specifiche dei requisiti attraverso
dimostrazione concreta.
-
Convalida del funzionamento del prodotto software secondo quanto progettato.
-
Convalida dell'appropriata implementazione dei requisiti.
Esiste un'interessante differenza tra il Test e le altre discipline in RUP - essenzialmente al Test viene attribuita la
funzione di ricerca ed esposizione delle debolezze nel prodotto software. È interessante perché, al fine di ottenere il
maggior profitto, è necessaria una filosofia generale differente rispetto a quella utilizzata per le discipline
Requisiti, Analisi & Progettazione e Implementazione. Una differenza piuttosto sottile è che mentre queste tre
discipline sono focalizzate sulla completezza, il Test è focalizzato sull'incompletezza.
Un buon impegno del test è guidato da questioni come:
-
le modalità di arresto del software
-
le possibili situazioni in cui il software non funziona nel modo previsto
Il Test si confronta con le assunzioni, i rischi e l'incertezza inerenti al lavoro di altre discipline e li affronta
utilizzando dimostrazioni concrete e valutazioni imparziali. È necessario evitare due potenziali estremi:
-
un approccio che non si confronta nel modo adatto o effettivo con il software ed espone i suoi inerenti problemi o
debolezze
-
un approccio inappropriatamente negativo o distruttivo - con tale approccio è impossibile considerare il prodotto
software qualitativamente accettabile e l'impegno del Test può risultare alienato dalle altre discipline
Le informazioni presentate nelle diverse valutazioni e prove asseriscono che i test sul software coprono dal 30% al 50%
dei suoi costi di sviluppo complessivi. È dunque in qualche modo sorprendente notare come la maggior parte delle
persone creda che il software per computer non venga adeguatamente testato prima della distribuzione. Questa
contraddizione nasce da un ristretto numero di problematiche chiave:
-
I test di un software sono molto complessi. Si tratta di quantificare i differenti modi in cui un dato programma
può comportarsi.
-
Generalmente i test vengono effettuati senza una precisa metodologia, ottenendo in questo modo risultati variabili
da progetto a progetto e da organizzazione a organizzazione. Il successo è innanzitutto un fattore della qualità e
delle abilità degli individui.
-
Gli strumenti della produttività vengono utilizzati in modo insufficiente, il ché rende ingestibili i laboriosi
aspetti dei test. Oltre alla mancanza di esecuzioni di test automatizzate, molti impegni del test vengono condotti
senza gli strumenti adatti a gestirne dati e risultati estesi. La flessibilità d'uso e la complessità del software
rendono impossibile l'obiettivo di un test completo. Utilizzando una metodologia ben concepita e strumenti "allo
stato dell'arte" è possibile migliorare sia la produttività che l'efficienza dei test sul software.
Un software di alta qualità è essenziale per il successo di sistemi critici per la sicurezza - quali il
controllo del traffico aereo, la guida per missili o sistemi di produzione medica - per i quali un errore può
comportare danni alle persone. La criticità di un tipico sistema MIS può non essere immediatamente ovvia, ma è
probabile che l'impatto di un difetto possa avere ripercussioni in uno scenario business, attraverso una considerevole
spesa per il software, con perdita di profitti e costi legali. In questa epoca dell'informazione, con una crescente
richiesta di servizi in formato elettronico su internet, molti sistemi MIS vengono ora considerati critici per la
sicurezza; ossia, le compagnie non riescono a soddisfare le proprie funzioni e subiscono perdite ingenti quando si
verificano errori.
Un continuo approccio alla qualità, iniziato da subito nel ciclo vitale del software, può diminuirne i costi del
completamento e della gestione in modo significativo. È un approccio che riduce enormemente i rischi associati alla
distribuzione di software di bassa qualità.
La disciplina del test è collegata ad altre discipline, come esposto di seguito:
-
La disciplina Requisiti acquisisce i requisiti per il prodotto software, uno dei primi
input per l'identificazione dei test da eseguire.
-
La disciplina Analisi
& Progettazione determina il progetto appropriato per il prodotto software, altro importante input
per l'identificazione dei test da eseguire.
-
La disciplina Implementazione produce build del prodotto software convalidati dalla
disciplina del test. All'interno di un'iterazione, vengono testati multipli build - uno per ciclo di test.
-
La disciplina
Distribuzione distribuisce il prodotto completo all'utente finale. Mentre
il software viene convalidato dalla disciplina del test prima di ciò, la verifica beta e la verifica di
accettazione sono spesso condotte in fase di distribuzione.
-
La disciplina di Ambiente sviluppa e gestisce gli artefatti di supporto utilizzati durante
il test, come le linee e l'ambiente.
-
La disciplina di Gestione progetto pianifica il progetto e il lavoro necessario in ogni
iterazione. Descritto in un piano d'iterazione, questo artefatto rappresenta un importante input utilizzato nella
definizione della missione di valutazione per l'impegno del test.
-
La disciplina di Configurazione & Gestione modifiche controlla le modifiche all'interno
del team di progetto. L'impegno del test verifica che ogni modifica sia stata completata in modo appropriato.
È consigliata la lettura di Kaner, Bach & Pettichord's Lessons Learned in Software Testing [KAN01], che contiene un'eccellente raccolta di importanti questioni per i team di
test.
|