La ricerca degli errori presenti nel software

La ricerca degli errori presenti nel software

La ricerca degli errori (o bug) presenti nel software è una pratica, che è stata condotta troppo spesso con criteri personali e talvolta senza alcuna metodologia: un’attività così organizzata e poco documentata è senza dubbio scarsamente produttiva, oltre che potenzialmente confusionaria e poco efficiente. È importante, così come si fa con un’applicazione, dedicare del tempo alla creazione della documentazione iniziale, che costituisce una linea guida per la realizzazione dell’attività di test. Una completa documentazione dovrebbe essere costituita da:

  1. Un piano di test (Software Testing Plan Documentation), nel quale viene descritta nei particolari l’intera attività di test;
  2. Una descrizione dei test-case (Software Testing Description Documentation), nel quale viene indicato l’oggetto del test, i valori ricevuti in ingresso, il risultato atteso e quello riscontrato (ciascun oggetto del test avrà il suo testcase);
  3. Un report dei test-case (Software Testing Report Documentation), nel quale viene indicato il risultato del caso di test.

La ricerca degli errori presenti nel software
La ricerca degli errori presenti nel software

Un test-case (o test case) è un particolare insieme di dati e procedure utilizzati per controllare il comportamento di un preciso aspetto del programma; sono progettati prima di eseguire fisicamente i test, ed un gruppo di test-case costituisce un test suite. La documentazione e l’insieme delle prove possono essere suddivise tra differenti tester al fine di minimizzare i tempi o intensificare l’attività di ricerca delle anomalie, riunendo, poi, tutta la documentazione creata in un unico piano di test finale.
La creazione di un’efficiente documentazione non è il solo problema che si pone nella pianificazione di un’attività di test. Anche la scelta del momento è un passo importante, considerando aspetti come il tempo effettivo rimanente, il numero di tester disponibili, la qualità che si desidera raggiungere; aspetti che non possono essere trascurati, e che condizionano direttamente l’attività di test modificandone la durata e le fasi. Inoltre, tester e sviluppatori hanno generalmente una visione differente delle cose. Il documento, oltre a costituire un punto di riferimento per le future attività dell’azienda, andrà in mano al cliente: questo dovrebbe far capire l’importanza di un elaborato preciso, chiaro, completo.

Il fondamento di una buona attività di test è sicuramente la scelta del momento nel quale iniziare la ricerca dei bug. Storicamente si sono diffusi principalmente due approcci: quello a cascata, che prevede l’esecuzione dei test a prodotto concluso, una volta che gli sviluppatori dispongono di una “beta” stabile del prodotto, e quello iterativo incrementale, che segue, invece, lo sviluppo del software. Il concetto è fortemente legato all’eXtreme Testing. Quale differenza esiste tra i due approcci? L’approccio a cascata è facile da mettere in pratica e da organizzare, ma i suoi limiti sono evidenti con grossi progetti: se la realizzazione di un prodotto portasse via dei mesi, fino al prodotto concluso non avremmo possibilità di verificare l’aderenza alle specifiche progettuali, ai requisiti dell’utente, ai requisiti di qualità, etc. Il rischio di un lavoro mal fatto e lontano dalle richieste dell’utente è alto.

Come alternativa all’approccio a cascata, quello iterativo incrementale prevede a priori una scomposizione del prodotti in unità; le unità vengono implementate singolarmente, testate ed inserite in opportune release, che essendo costituite da ridotti gruppi di funzionalità, sono più facilmente analizzabili. A man mano che la produzione del software va avanti il prodotto viene incrementato di nuove unità e testato nuovamente nel complesso. L’attività di test affianca così da subito l’attività di produzione, verificando l’aderenza agli standard, ai requisiti, agli obiettivi, etc… Una migliore organizzazione e rispetto delle specifiche consente, anche, un migliore coinvolgimento del cliente, che può verificare l’attività dell’azienda alla quale ha commissionato il lavoro. Per contro, tale approccio richiede però un’attenta pianificazione iniziale che stabilisca tempi e contenuti delle release da esaminare e discutere con il cliente. È chiaro che vi deve essere anche una disponibilità da parte del cliente stesso di visionare periodicamente dette release, cosa non sempre possibile.

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 *