Come creare e scrivere un piano di test software

Come creare e scrivere un piano di test software

Piano di test

Dalla trattazione dell’IEEE 829 emerge come il punto più interessante da trattare sia quello legato alla creazione del piano di test: si tratta di un documento fondamentale per organizzare e documentare il lavoro non solo all’interno dell’organizzazione ma anche esternamente; infatti esso verrà letto dai clienti che apprenderanno i dettagli operativi delle fasi di test e quanto è stato svolto. Il documento deve necessariamente essere completo e facile da leggere. Ogni prodotto richiede un suo piano di test specifico, e anche se all’inizio può risultare complesso, perché in effetti si tratta di un documento articolato, ma si prende facilmente la mano dopo poche prove.

Le 6 fasi di cui si compone il test (pianificazione, progettazione, codifica, esecuzione, revisione e controllo, valutazione) creano ognuna una certa quantità di materiale cartaceo che una volta raccolto, crea il piano di test definitivo. È dunque chiaro che il piano di test stesso, è la raccolta di un certo numero di documenti più piccoli, redatti dai responsabili di ciascun ambito in un determinato arco temporale.
In effetti, è stato notato come delle volte molte aziende provvedano solo a lavori ultimati alla redazione di tali documenti, che hanno un ruolo quasi riassuntivo, più che descrittivo; un approccio a mio parere non corretto, in quanto produce materiale non valido, inesatto, sommario. L’obbiettivo del piano di test è proprio quello di creare un valido punto di riferimento per l’organizzazione; è quindi necessario impegnarsi al fine di ottenere uno strumento valido ed efficiente.

Come creare e scrivere un piano di test software

Il piano di test, in particolare se si segue un template per la qualità, avrà forma generale; per adattarlo alle specifiche eseigenze di progetto si possono seguire questi punti:

  1. Avere chiare tutte le funzionalità del prodotto ed i singoli risultati che debbono essere generati dall’applicazione in risposta agli stimoli esterni (è necessario disporre dei manuali utente);
  2. Suddividere il prodotto per funzionalità o moduli;
  3. Elaborare i test case per ogni funzionalità o modulo;
  4. Raccoglierli e completare il piano di test con le considerazioni generali.

Queste fasi di lavoro consentono di poter predisporre un piano di test per qualunque progetto da trattare.
Per piccoli progetti, è spesso difficile creare così tanta documentazione nelle singole fasi; questo perché talvolta l’attività di test è svolta da una singola persona o perché effettivamente, il tempo necessario per redarre ogni singolo documento è elevato. Si rischia così di impiegare più tempo per redarre il documento che non per effettuare i singoli test, vero obbiettivo del nostro lavoro. In altre parole, stiamo perdendo di vista la missione preposta. Seguendo un template elaborato a priori, possiamo accelerare le fasi di lavoro; si tratterà solo di inserire nella documentazione già predisposta i seguenti aspetti (se mancanti), completandoli opportunamente in modo da adattarli al nostro caso specifico:

  • Gli obbiettivi del processo di test
  • Il peso dell’attività di test sulla produzione del software
  • Il livello di accettabilità di test
  • La definizione delle attività di test
  • I controlli da eseguire sulle singole attività
  • Il peso di ciascuna attività sull’attività complessiva di test
  • I documenti da produrre ed archiviare
  • Il grado di copertura del codice
  • Le tecniche di test da utilizzare
  • I criteri di scelta delle tecniche

Gli obbiettivi del processo di test identificano le finalità che il test si prefigge; correttezza, completezza, miglioria del livello qualitativo del prodotto sono alcune di esse.
Inoltre, il peso dell’attività di test sulla produzione del software è fondamentale per l’attività di test da condurre.
D’altro canto, il livello di accettabilità indica il grado di bontà ritenuto sufficiente ai fini di una analisi completa ed efficace. Può essere collegato al grado di copertura: una volta raggiunto, il nostro test può essere ritenuto accettabile. Diversamente, può essere ricondotto al numero o alla tipologia di bug rilevati (critici/gravi). Va pianificato a priori e si tratta di una fase operativa.

La definizione delle attività mira ad identificare quali siano le operazioni da compiersi per operare correttamente, ovvero: individuazione delle competenze, suddivisione dei compiti, addestramento del personale, etc.
I controlli da eseguirsi sulle singole attività sono collegate alle singole competenze di chiunque prenda parte all’attività di test, qualunque sia il suo ruolo: un capo progetto verificherà che le operazioni vengano svolte secondo quanto progettato, con diligenza e professionalità.
Il peso di ciascuna attività sull’attività di test identifica quanto tempo occorre destinare ad ogni compito. Ciò può dipendere da fattori come l’importanza dell’attività, il tempo a disposizione etc.
I documenti da produrre ed archiviare costituiscono invece una fase descrittiva dei principali elaborati che occorre considerare e produrre affinché esista un piano completo ed esauriente dell’opera: possono essere utili organigrammi, diagrammi temporali (di Gantt), delle competenze, dei costi etc. La loro scelta è a discrezione del capo progetto.
Il grado di copertura del codice è invece una soglia di accettabilità per il test stesso; maggiore sarà la copertura del codice, più precisa risulterà l’attività stessa, come già descritto in precedenza.
Le tecniche di test sono le metodologie utilizzate per eseguire l’analisi, che vanno valutate alla luce del tipo di applicazione da testare e degli strumenti e competenze a disposizione. Infine, le scelte che hanno portato a preferire una metodologia anziché un’altra vanno documentate opportunamente.

Quali costi per il test

La formazione del personale di test, il tempo necessario per la creazione del piano di test e della documentazione, non devono essere unicamente intesi come un costo: costituiscono invece un investimento per la società. Si investe in formazione e si ottiene un incremento delle potenzialità interne dell’azienda, guadagnando sul piano professionale/formativo dei dipendenti. Al di là di questo, in effetti, il costo c’è ed occorre valutarlo attentamente, anche perché la visione del “costo” dell’attività è differente nel caso del tester o dello sviluppatore.

Più precisamente, i costi sono suddivisibili in:

  1. costi per la prevenzione, miranti a prevenire mancanze di qualità del prodotto (analisi a priori)
  2. costi per la valutazione, miranti a determinare mancanze di qualità (analisi a posteriori)
  3. costi di fallimento, derivanti dalla mancanza di qualità e necessari per sostenere la correzione dei bug, che si dividono in:
    • costi di fallimento interni, che riguardano il prodotto prima che questo sia consegnato
    • costi di fallimento esterni, che riguardano il prodotto dopo che questo sia consegnato

I costi totali della qualità sono dunque la somma di diverse componenti, quali: Prevenzione + Valutazione + Fallimenti.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *