Quali sono i problemi e gli errori tipici del testing software

Quali sono i problemi e gli errori tipici del testing software

Errori tipici del testing

In informatica, il software testing è definito come un’attività per verificare se i risultati effettivi corrispondono ai risultati previsti e per garantire che il sistema software sia privo di difetti. Implica l’esecuzione di un componente software o componente di sistema per valutare una o più proprietà di interesse. Il test del software consente inoltre di identificare errori, lacune o requisiti mancanti in contrasto con i requisiti effettivi.

Quali sono i problemi e gli errori tipici del testing software

In effetti, svolgere con attenzione e accuratezza una fase di testing, non è cosa davvero facile; i problemi che si riscontrano possono essere dovuti ai seguenti motivi.

Una difficile progettazione dell’applicazione

Spesso gli sviluppatori non rendono la vita facile ai tester. In alcuni progetti complessi o particolari, ed in presenza di esplicite richieste del cliente, i prodotti software possono essere realizzati secondo forme poco organiche e scorrevoli. Questo non è da confondersi con l’efficienza; anche se una forma contorta porta quasi sempre ad un risultato non buono, questo non è valido nella totalità dei casi, in quanto è possibile trovare anche in commercio programmi che pur essendo poco “user friendly”, cioè amichevoli nelle interfacce o nelle routine, svolgono il loro lavoro correttamente ed in maniera efficiente. Anche se la nostra tecnica di test non sarà White Box, cioè non saremmo portati a conoscenza dei dettagli implementativi dell’applicazione, un prodotto poco chiaro certamente non ci renderà la vita facile, in quanto molti sforzi dovranno essere fatti per comprenderne a pieno le funzionalità, gli aspetti, i significati delle varie parti e gli output attesi. È dunque importante poter disporre da subito di un prodotto ben realizzato anche esteticamente da poter testare; diversamente, una parte anche considerevole di tempo iniziale potrebbe essere persa per far capire ai tester il reale funzionamento del prodotto stesso.

Cattiva organizzazione delle fasi di test

Saper organizzare bene il proprio lavoro è la chiave di una buona attività di test. Non conoscere le fasi in cui si articola una operazione di test, rende senza dubbio difficile il tutto. I tester devono avere chiari i loro obbiettivi (ricerca bug, segnalazione, verifica qualità ecc) e devono essere in grado di pianificare le proprie attività; una certa parte di esse saranno vincolate (come le scadenze alle quali presentare documentazioni o le ore nelle quali sarà possibile testare); altre saranno liberamente gestibili (come le sequenze operative, quale modulo testare, ecc).

Cattiva suddivisione del lavoro

Può una cattiva organizzazione interna incidere sull’attività di test? Credo sinceramente di sì. Il problema comporta quasi sempre una non ottimale pianificazione delle attività che si riflette in una errata suddivisione dei compiti tra i membri del progetto, con conseguimento di risultati spesso non soddisfacenti. È importante creare un buon ambiente di lavoro, in grado di stimolare e incentivare i membri all’attività dell’azienda.

Scelta di una tecnica di test non idonea

Anche una cattiva scelta della tecnica può rivelarsi un serio problema; abbiamo già visto come ogni tecnica abbia le proprie funzionalità che la contraddistingue dalle altre; esistono molteplici tecniche proprio per fare in modo di venire incontro alle molteplici esigenze di progetto. È vero che la scelta può essere molto ampia e disorientare, ma la causa principale dell’utilizzo di una errata tecnica, è la mancanza di conoscenze delle tecniche effettivamente disponibili, delle loro proprietà e delle modalità d’applicazione.

Scostamento dagli obbiettivi prefissati

Lo scostamento dell’operato del tester dagli obbiettivi prefissati è un discorso più complesso ed ampio dei precedenti. La mancanza di qualità del prodotto viene attribuita alla equipe responsabile della progettazione e dello sviluppo; ma in questo caso, qual’è il ruolo dietester? La loro attività è mirata non solo a identificare errori nel prodotto (assicurando così la qualità ai consumatori finali), ma sopratutto ad identificare gli errori realmente importanti e fondamentali che occorre eliminare. Ma il concetto di gli aspetti importanti in un prodotto sono strettamente legati alla clientela, ai loro obbiettivi, utilizzi del prodotto, classe di età, occupazione etc. è logico pensare che un utente professionista (grafico, ingegnere, architetto) abbia necessità di un prodotto con elevati standard qualitativi che necessitano dunque di un maggior lavoro per i tester.

A questo punto il tester deve preoccuparsi di verificare che il prodotto non si discosti dal comportamento voluto, non che il prodotto soddisfi la clientela o che sia utile; il confine tra questi due aspetti, seppur sottile è comunque importante. Del resto il tester non è neanche detto che sia a conoscenza delle potenzialità del prodotto o dei vari aspetti implementativi e funzionali, che gli sviluppatori possono celare per questioni di tutela del prodotto stesso. I tester sono spesso le uniche persone in una organizzazione che usano pesantemente il programma simulando un’ utenza esperta, notando el problematiche di utilizzo che gli utenti finali vedranno. l’utenza finale è spesso poco portata, se non per ragioni di esasperazione/disperazione a segnalare le anomalie del prodotto (sempre che siano in grado di distinguere un’ anomalia dalla caratterisict a intrinseca del prodotto), ed hanno appreso, in seguito a contati con responsabili dell’assistenza meno competenti di loro, che il tempo perso per segnalare le anomalie è tempo sprecato.

E’ del resto vero che molte aziende si impegnano attivamente perconoscere i pareri e i problemi dell’utenza per migliorare il prodotto, legandolo a loro quasi in un rapporto confidenziale mirato ad aumentare i rapporti; diversamente, un cliente non si fa mettere nel sacco due volte, e si orienterà verso un prodotto/azienda che gli garantiscano maggiori risultati e che lo stiano a sentire se ha necessità. E’ compito del tester impedire questa perdita di clientela, assicurando un prodotto perlomeno funzionale ed efficiente.

Il miglioramento diretto è possibile solo nel momento in cui l’analisi inizi in ritardo, e ulteriori organizzazioni sul lavoro non producano i risultati voluti nei tempi voluti. Il tester assume così anche il ruolo di “riparatore”. Va anche considerato che i clienti comunicheranno i difetti per loro rilevanti, ma non è detto che tutte queste defezioni emergano tramite essi, magari perché esistono “zone a rischio” nel programma maggiormente utilizzate o maggiormente stressate di altre.

In molte organizzazioni, il tester è spesso un novizio inquadrato in ruolo dove non possa creare “danni” allo sviluppo dei prodotti. In realtà questa affermazione presenta due inconvenienti:

  1. Il tester deve immedesimarsi nell’utilizzatore finale, e senza il suo operato, un intero lavoro può valere poco;
  2. Il tester è una figura che va creata, istruita, e che necessita di forti esperienze per poter operare al meglio: cioè tutto l’opposto di un novizio.

Inoltre. l’attività di testing non deve essere limitata alla sola prova, ma anche alla pianificazione delle attività di test, una fase forse non entusiasmante quanto l’esecuzione delle prove; occorre però prestare attenzione a non abbondare nell’uno o nell’altro campo, creando così squilibri nell’analisi.

E’ importante a questo punto capire in cosa consiste undisegno di prova: si tratta semplicemente di una progettazione della fase di test che incorpora differenti elementi quali descrizioni del problema e delle analisi da effettuare, configurazione del sistema sul quale si esegue la prova (la configurazione potrebbe influire in una certa misura sull’esito delle prove) ed una descrizione dei risultati previsti. Occorre evitare di essere esageratamente specifici nelle descrizioni.

Attriti interni

Un altro errore classico, coinvolge le relazioni tra tester e programmatore. Alcuni programmi sono principalmente creati sulla base di interfacce utente, altri ne sono totalmente privi (p.e. software embedded), rendendo difficile il compito di un tester che non è in grado di stabilire il confine e le conoscenze idonee alla esecuzione delle prove. In questi casi, il tester si basa sulle conoscenze del programmatore, che può aggiungere nel codice dei “punti di sostegno” che esistono per sostenere le attività di valutazione del prodotto.

Cattiva Comunicazione

Una volta individuata, l’anomalia va preò segnalata. Una cattiva comunicazione è un errore ricorrente, anche perché in alcuni casi non esistono metodologie che permettano di riprodurre l’errore in maniera esatta, e la sua descrizione risulterà peraltro contorta e complessa. Il lavoro del tester deve essere documentato con severità e precisione, in modo che le altre persone che leggono il report capiscano effettivamente i problemi e ci pongano mano. Ma non tutti i bug sono comunicati dal tester; molti, sono comunicati dai clienti, il che farebbe supporre che il tester abbia
eseguito male il proprio lavoro. Questa affermazione non è sempre vera, ed un bug rivelato da un cliente è per il tester come un suggerimento, un consiglio su come migliorare la propria attività in futuro.

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 *