Come eseguire i test software in modo efficiente

Come e quando operare nel test

La ricerca delle anomalie presenti nel software (testing 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 della attività di test. Una completa documentazione dovrebbe essere costituita da:

1. Un piano di test, nel quale viene descritta nei particolari l’intera attività di test
2. Un test case, nel quale viene indicato l’oggetto del test, i valori ricevuti in input, l’output atteso e quello riscontrato (ciascun oggetto del test avrà il suo test case);
3. Un report del test case, nel quale viene indicato il risultato del test case (OK per assenza di anomalia, ERRORE per presenza di anomalie e loro descrizione).

Un 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 una 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.

Scegliere l’ambiente per il test

Gli approcci a cascata o iterativo incrementale consentano di pianificare ed organizzare l’attività di test. Un aspetto interessante, che si presenta soprattutto col secondo approccio, è costituito dal disporre di un’unica copia del prodotto comune a tester e sviluppatori oppure di creare due copie distinte di lavoro che vengano aggiornate di pari passo.
Se la versione è comune vi possono essere difficoltà di aggiornamenti improvvisi, numerosi accessi al server, confusione generale; creando invece due copie distinte molti di questi aspetti sono risolti. Solitamente, le due versioni sono presenti su server distinti, al fine di evitare che vi siano interferenze reciproche nel lavoro. Alla risoluzione di nuovi bug ed in presenza del rilascio di nuove release gli sviluppatori provvedono a sostituire la versione di prova dei tester con una nuova nella quale sono state implementate nuove funzionalità. Questo approccio richiede il più delle volte una metodologia di test regressivo, come verrà spiegato nel seguito.

Chi deve effettuare il test

La scelta delle persone più idonee ad effettuare il test deve essere effettuata in fase di elaborazione della documentazione iniziale, nella quale vengono individuati sia i soggetti coinvolti che le singole competenze. L’attività di test è un’attività complessa nella quale è richiesta pratica, esperienza ed una necessaria formazione del personale addetto, al fine di ottenere risultati soddisfacenti: non si tratta di un’attività nella quale inserire personale non adatto per altri ruoli; se la si ritiene secondaria, significa che non si ha compreso la sua importanza nella fase di produzione del software.
La formazione del personale, necessaria per assicurare un buon livello operativo può essere affidata a terzi, società esperte nel settore che si occupa di formazione delle risorse umane: corsi, stage, documentazione costituiscono un necessario supporto per l’acquisizione delle informazioni necessarie. Così come per svolgere un’attività di programmazione e di sviluppo in genere occorre documentarsi, studiare, formarsi, così anche l’attività di test necessità di competenze adeguate, per non trasformarsi in una reale perdita di tempo per il rilascio del prodotto.

Chi dovrebbe eseguire il test? Nella realtà esistono due possibilità:

1. Affidare il test alla stessa organizzazione che ha realizzato il software (alpha test);
2. Affidare il test ad una organizzazione esterna (beta test).

I due casi si concentrano solo sul chi deve eseguire i test, non dicendo nulla sul come eseguirli. Possiamo comunque affermare che dal punto di vista della qualità, accentrare nelle stesse mani realizzazione e collaudo è eccessivo, non tanto per la mole di lavoro, quanto per la fiducia di ottenere buoni risultati (difficilmente chi realizza un software è portato a ragionare in termini distruttivi se i bug lo richiedono).

Non solo: la visione del problema di uno sviluppatore è fondamentalmente differente da quella dei tester. I primi, hanno determinate conoscenze e capacità creative, e sono spesso “ancorati” alle proprietà e caratteristiche del particolare linguaggio utilizzato per la creazione dell’applicazione; i secondi invece sono spesso ignari di programmazione e tendono ad avere una visione complessiva del problema imparziale e particolarmente vicina al modo di pensare dell’utente, più che alla macchina. Ne consegue che se “due occhi sono meglio di uno” allora l’attività di test è bene sia svolta da personale esterno. Ovviamente occorre evitare che tale attività si trasformi in un attrito interno tra sviluppatori e tester facilmente generabile a fronte di numerosi errori del prodotto, ma in un attività costruttiva e dinamica.