Spiegazione completa dei Principi del testing software

Testing software

Il testing software è il processo o il metodo per individuare gli errori in un’applicazione o programma software in modo che l’applicazione funzioni in base alle esigenze dell’utente finale.
In altre parole, il test del software è il processo di verifica di un sistema con lo scopo di identificare eventuali errori, difetti o requisiti mancanti rispetto ai requisiti effettivi.

Il test del software è un’attività preziosa nello sviluppo del software, ma spesso viene fraintesa a causa della sua natura imprevedibile e creativa. Uno dei motivi per cui testiamo è scoprire problemi, rischi e altre informazioni su un prodotto software, consentendo di intraprendere un’azione in modo che l’utente finale non ne venga influenzato negativamente. Questa azione potrebbe essere:

1. Correzione di bug
2. Rivalutazione e modifica dei requisiti originali
3. Fornire assistenza all’utente all’interno del prodotto
4. Creazione della documentazione per l’utente
5. Comunicare problemi noti alle parti interessate.

Principi del testing sul software

I principi svolgono un ruolo importante in tutte le discipline ingegneristiche e sono di solito introdotti come parte di un background educativo in ogni ramo di ingegneria.

I principi del testing sono importanti per gli specialisti del testing e per gli ingegneri perché forniscono le basi per lo sviluppo della conoscenza dei test e per l’acquisizione delle capacità di test. Forniscono anche una guida per la definizione delle attività di test eseguite nella pratica da uno specialista di test. Un principio può essere definito come:

1. una legge, una dottrina o una supposizione generale o fondamentale;
2. una regola o un codice di condotta;
3. le leggi o fatti della natura alla base del funzionamento di un dispositivo artificiale.

Estendendo queste tre definizioni al dominio dell’ingegneria del software possiamo dire che i principi di ingegneria del software si riferiscono a leggi, regole o dottrine che riguardano i sistemi software, come costruirli e come questi sistemi si comportano. Nel dominio del software, i principi possono anche fare riferimento a regole o codici di condotta relativi ai professionisti che progettano, sviluppano, testano e mantengono i sistemi software. Il test come componente della disciplina dell’ingegneria del software ha anche una serie specifica di principi che servono da linee per il tester. Guidano i tester nel definire come testare i sistemi software e fornisce regole di condotta per i tester come professionisti. Glenford Myers ha delineato un tale insieme di principi di test basati sull’esecuzione nel suo libro, The Art of Software Testing. Alcuni di questi principi sono descritti di seguito. I principi 1-8 e 11 sono derivati direttamente dal set originale di Myers. L’autore ha riformulato questi principi e ha anche apportato modifiche al set originale per riflettere l’evoluzione di test da un’arte, a un processo legato alla qualità nel contesto di una disciplina ingegneristica. Si noti che i principi indicati di seguito si riferiscono solo ai test basati sull’esecuzione.

Principio 1

Il test è il processo di esercitare un componente software utilizzando un insieme selezionato di casi di test, con l’intento di rivelare difetti e della valutazione della qualità. Gli ingegneri del software hanno fatto grandi progressi nello sviluppo di metodi per prevenire ed eliminare i difetti. Tuttavia, i difetti si verificano e hanno un impatto negativo sulla qualità del software. I tester devono rilevare questi difetti prima che il software diventi operativo. Questo principio supporta il test come attività basata sull’esecuzione per rilevare i difetti. Supporta anche la separazione dei test dall’attività di debugging poiché l’intento di quest’ultima è quello di individuare difetti e riparare il software. Viene usato il termine “componente software” in questo contesto per rappresentare qualsiasi unità di software che varia in dimensioni e complessità da una singola procedura o metodo ad un intero sistema software. Il termine “difetto” utilizzato in questo e nei principi successivi rappresenta eventuali deviazioni nel software che hanno un impatto negativo le sue funzionalità, prestazioni, affidabilità, sicurezza e/o qualsiasi altro dei suoi attributi di qualità specificati.

Principio 2

Quando l’obiettivo del test è rilevare i difetti, allora un buon caso di test è quello che ha un’alta probabilità di rivelare un difetto non ancora rilevato. Il principio 2 supporta un’accurata progettazione del test e fornisce un criterio con cui valutare la progettazione del caso di test e l’efficacia dello sforzo del test quando l’obiettivo è quello di rilevare i difetti. Richiede che il tester prenda in considerazione l’obiettivo per ogni caso di test, cioè quale tipo specifico di difetto deve essere rilevato dal caso di test. In questo modo il tester si avvicina al test allo stesso modo uno in cui scienziato si avvicina ad un esperimento. Nel caso dello scienziato c’è un’ipotesi implicita che vuole provare o confutare per mezzo dell’esperimento. Nel caso del tester, l’ipotesi è correlata alla presunta occorrenza di specifici tipi di difetti. L’obiettivo per il test è di dimostrare/confutare l’ipotesi, cioè determinare se lo specifico difetto è presente/assente. In base all’ipotesi, gli input dei test sono selezionati, le uscite corrette sono determinate e il test viene eseguito. I risultati sono analizzati per dimostrare/confutare l’ipotesi. Bisogna rendersi conto che molte risorse vengono investite in un test, risorse utilizzate per progettare i casi di test, per eseguire i test e per registrare e analizzare i risultati. Un tester può giustificare la spesa delle risorse mediante un’accurata progettazione dei test in modo tale che il principio 2 sia supportato.

Principio 3

I risultati dei test devono essere controllati meticolosamente. I tester devono ispezionare attentamente e interpretare i risultati dei test. Diversi scenari nefasti e costosi si possono verificare se non si presta attenzione. Per esempio:

1. Un errore può essere trascurato e al test può essere concesso un “passaggio” di stato quando in realtà il software ha fallito il test. Il test può continuare sulla base di risultati errati del test. Il difetto può essere rivelato in una fase successiva di test, ma in tal caso potrebbe essere più costoso e difficile da individuare e riparare.
2. Si può sospettare un fallimento quando in realtà non esiste. In questo caso al test può essere concesso lo stato di “fallimento”. Può essere speso molto tempo e sforzo per cercare di trovare il difetto che non esiste. Un attento esame dei risultati del test potrebbe alla fine indicare che nessun fallimento è presente.
3. Il risultato di un test di qualità può essere frainteso, con conseguente rilavorazione non necessaria o supervisione di un problema critico.

Principio 4

Un caso di test deve contenere l’output o il risultato atteso. È spesso ovvio per un tester principiante che gli input dei test devono essere parte di un caso di test. Tuttavia, il caso di test non ha alcun valore a meno che non ci sia una esplicita dichiarazione dei risultati o degli output attesi, ad esempio uno specifico valore di una variabile deve essere osservato o un determinato pulsante del pannello deve illuminarsi. Le uscite previste consentono al tester di determinare (i) se ha un difetto è stato rivelato e (ii) se il test è stato superato/non superato. È molto importante avere una dichiarazione corretta dell’output in modo da non spendere tempo inutile a causa di idee sbagliate sull’esito di un test. Le specifiche degli ingressi e delle uscite dei test dovrebbero far parte delle attività di progettazione dei test. Nel caso di test per la valutazione della qualità, è utile per gli obiettivi della qualità esprimere il test, se possibile, in termini quantitativi nel documento dei requisiti, in modo che i tester siano in grado di confrontare gli attributi software attuali come determinato dai test con ciò che è stato specificato.

Principio 5

I casi di test dovrebbero essere sviluppati per condizioni di input validi e non validi. Un tester non deve presumere che il software in prova sarà sempre fornito di input validi. Gli input potrebbero essere errati per diversi motivi. Ad esempio, gli utenti di un software potrebbero avere incomprensioni o mancanza di informazioni sulla natura degli input. Spesso si fanno errori tipografici anche quando sono disponibili informazioni complete e corrette. I dispositivi possono fornire anche input non validi a causa di condizioni errate e malfunzionamenti. L’utilizzo di casi di test basati su input non validi è molto utile per rivelare i difetti poiché possono eseguire il codice in modi imprevisti e identificare un comportamento inaspettato del software. Gli input non validi aiutano inoltre gli sviluppatori e i tester a valutare la robustezza del software, ovvero la sua capacità di recuperare quando si verificano eventi imprevisti (in questo caso un input errato). Il principio 5 supporta la necessità del gruppo di test indipendente richiesto nel principio 7 per il seguente motivo. Lo sviluppatore di un componente software può essere influenzato nella selezione degli ingressi dei test per il componente e specificare solo input validi nei casi di test per dimostrare che il software funziona correttamente. Un tester indipendente è più adatto nel selezionare anche input non validi.

Principio 6

La probabilità dell’esistenza di ulteriori difetti in un componente software è proporzionale al numero di difetti già rilevati in quel componente. Ciò che questo principio dice è che maggiore è il numero di difetti già rilevati in un componente, maggiore è la probabilità di avere ulteriori difetti quando viene sottoposto a ulteriori test. Ad esempio, se ci sono due componenti A e B, e i tester hanno trovato 20 difetti in A e 3 difetti in B, allora la probabilità dell’esistenza di difetti aggiuntivi in A è maggiore di B. Questa osservazione empirica può essere dovuta a diverse cause. I difetti si verificano spesso in gruppi e spesso nel codice che presenta un alto grado di complessità e che è stato mal progettato. Nel caso di tali componenti, gli sviluppatori e i tester devono decidere se ignorare la versione corrente del componente e lavorare su una riprogettazione o pianificare un impiego di risorse per test aggiuntivi su questo componente per assicurarsi che soddisfi i propri requisiti. Questo problema è particolarmente importante per i componenti che implementano funzioni critiche di sicurezza o di missione.

Principio 7

I test dovrebbero essere eseguiti da un gruppo che è indipendente dal gruppo di sviluppo. Questo principio è valido sia per ragioni psicologiche che pratiche. È difficile per uno sviluppatore ammettere o concepire che quel software che ha creato e sviluppato possa essere difettoso. I tester devono rendersi conto che
(i) gli sviluppatori hanno un grande orgoglio nel loro lavoro e (ii) a livello pratico può essere difficile per loro concettualizzare dove potrebbero essere trovati difetti. Anche quando i test falliscono, gli sviluppatori hanno spesso difficoltà a localizzare perché il loro modello mentale del codice potrebbe oscurare la loro visione di codice come esiste in realtà. Possono anche avere idee sbagliate o incomprensioni riguardo ai requisiti e alle specifiche relative al software. Il requisito per un gruppo di test indipendente può essere interpretato da un’organizzazione in diversi modi. Il gruppo di tester potrebbe essere implementato come entità funzionale completamente separata nell’organizzazione. In alternativa, i tester potrebbero essere membri di un Gruppo di Garanzia di Qualità del Software, o anche essere una parte specializzata del gruppo di sviluppo, ma soprattutto, hanno bisogno della capacità di essere obiettivi. La segnalazione a una gestione separata dallo sviluppo può supportare la loro obiettività e indipendenza. Come membro di uno qualsiasi di questi gruppi, i compiti principali e la formazione dei tester dovrebbero trovarsi nei test piuttosto che nello sviluppo. Infine, l’indipendenza del gruppo di test non richiede una relazione contraddittoria tra sviluppatori e tester. I tester non dovrebbero giocare ai giochi “gotcha” con gli sviluppatori. I gruppi devono collaborare affinché un software di altissima qualità venga rilasciato al cliente.

Principio 8

Le prove devono essere ripetibili e riutilizzabili. Il principio 2 richiede a un tester di vedere il suo lavoro come simile a quello di uno scienziato sperimentale. Il principio 8 richiede che gli esperimenti nel dominio dei test richiedano la registrazione delle condizioni esatte del test, eventuali eventi speciali verificatisi, attrezzature utilizzate e un’attenta contabilizzazione dei risultati. Questa informazione è di inestimabile valore per gli sviluppatori quando il codice è restituito per il debug in modo che possano duplicare le condizioni di test. È utile anche per i test che devono essere ripetuti dopo la riparazione dei difetti. La ripetizione e il riutilizzo dei test sono necessari anche durante il test di regressione test del software che è stato modificato) nel caso di una nuova versione del software. Gli scienziati si aspettano che gli esperimenti siano ripetibili da altre persone, e i tester dovrebbero aspettarsi lo stesso!

Principio 9

I test dovrebbero essere pianificati. La pianificazione di test dovrebbe essere sviluppata per ciascun livello di test e per ogni livello dovrebbero essere descritti obiettivi nel piano associato. Gli obiettivi dovrebbe essere indicati il più quantitativamente possibile. I piani, con i loro precisi obiettivi specifici, sono necessari per garantire che i tempi e le risorse vengano assegnate per le attività di test e il test può essere monitorato e gestito. Le attività di pianificazione dei test devono essere svolte in tutto il ciclo di vita del software (principio 10). La pianificazione del test deve essere coordinata con la pianificazione del progetto. Il test manager e il project manager devono lavorare insieme per coordinare le attività. I tester non possono pianificare di testare un componente in una data a meno che gli sviluppatori non siano disponibili in quella data. I rischi del test devono essere valutati. Per esempio, quanto sono probabili ritardi nella consegna dei componenti software, quali componenti sono probabilmente più complessi e difficili da testare, i tester hanno bisogno di una formazione supplementare con nuovi strumenti? Un modello di pianificazione dei test deve essere disponibile al responsabile del test per guidare lo sviluppo del piano in base alle politiche e agli standard organizzativi. Un’attenta pianificazione dei test evita sprechi di test “usa e getta” e cicli improduttivi e non programmati di “test-patch-retest” che spesso portano a software di scarsa qualità e all’incapacità di consegnare il software in tempo e nel budget.

Principio 10

Le attività di test dovrebbero essere integrate nel ciclo di vita del software. Non è più possibile posticipare le attività di test fino a quando il codice è stato scritto. Testare le attività di pianificazione come supportate dal principio 10, dovrebbe essere integrato nel ciclo di vita del software a partire già dalla fase di analisi dei requisiti e continuare per tutto il ciclo di vita del software in parallelo con le attività di sviluppo. Oltre al piano di test, altri tipi di attività di test come i test di usabilità possono anche essere eseguiti all’inizio del ciclo di vita utilizzando prototipi. Questi attività possono continuare fino a quando il software non viene consegnato agli utenti. Le organizzazioni possono utilizzare modelli di processo come il modello a V o altri che supportano l’integrazione delle attività di test nel ciclo di vita del software.

Principio 11

Il testing è un compito creativo e stimolante. Le difficoltà e le sfide per il tester includono quanto segue:

• Un tester deve avere una conoscenza approfondita della disciplina di ingegneria del software.
• Un tester deve avere conoscenze sia dall’esperienza che dall’insegnamento su come il software viene specificato, progettato e sviluppato.
• Un tester deve essere in grado di gestire molti dettagli.
• Un tester deve avere conoscenza dei tipi di guasto e dei difetti di un certo tipo che potrebbero verificarsi nei costrutti di codice.
• Un tester deve ragionare come uno scienziato e proporre ipotesi che riguardano la presenza di tipi specifici di difetti.
• Un tester deve avere una buona conoscenza delle problematiche del dominio del software che sta testando. La familiarità con un dominio potrebbe derivare da esperienze educative, formative e lavorative.
• Un tester deve creare e documentare i casi di test. Per progettare il caso di test il tester deve spesso selezionare gli ingressi da un dominio molto ampio.

Quelli selezionati dovrebbero avere la più alta probabilità di rivelare un difetto (Principio 2). La familiarità con il dominio è essenziale.

• Un tester deve progettare e registrare procedure di test per l’esecuzione del test.
• Un tester deve pianificare le esecuzioni dei test e allocare le risorse appropriate.
• Un tester deve eseguire i test ed è responsabile della registrazione risultati.
• Un tester deve analizzare i risultati dei test e decidere sul successo o fallimento di un test. Ciò implica comprendere e tenere traccia di un’enorme quantità di informazioni dettagliate. Potrebbe essere richiesto anche un tester per raccogliere e analizzare le misurazioni relative ai test.
• Un tester deve imparare a usare gli strumenti e tenere il passo con i più recenti progressi degli strumenti di test.
• Un tester deve lavorare e collaborare con i tecnici dei requisiti, progettisti e sviluppatori e spesso devono stabilire un rapporto di lavoro con clienti e con gli utenti.
• Un tester deve essere educato e formato in questo settore specializzato e spesso gli sarà richiesto di aggiornare le proprie conoscenze su base regolare a causa del cambiamento delle tecnologie.