Cos'è il Testing o Collaudo del Software?
Vi è mai capitato di imbattervi in una offerta di lavoro e tra i requisiti è richiesto il Testing del Software? Scommetto che molti hanno pensato: "Ah, che bello! Vado a giocare a Candy Crush tutto il giorno ahahah ☺". Purtroppo non è così: il Collaudo del Software o Testing del Software è un insieme di attività necessarie affinchè si produca software di qualità riducendo al minimo il rischio di malfunzionamento del sistema o componente software.
Special thanks *
A seguire ci sono gli appunti di studio dell'
International Software Testing Qualification Board ISTBQ basati sul
Syllabus Livello "Foundation". Tutto il testo a seguire è una semplificazione ma non troppo del suddetto Syllabus. Se avete intenzione di studiare sul mio blog non lo fate...! Vi consiglio di leggere le mie note e poi approfondire sul testo originale. Partiamo...
Quali sono gli obiettivi tipici del testing?
Per ogni sistema software,
gli obiettivi del testing possono includere:
- La valutazione dei requisiti(1), le user story(2), la progettazione e del codice
- La verifica che tutti i requisiti specificati siano stati soddisfatti
- La validazione dell'oggetto di test in modo da assicurarsi che funziona come si attendono gli utenti e gli stakeholder
- L'aumento della fiducia in termini di miglioramento del livello di qualità dell'oggetto testato
- La prevenzione e la ricerca di failure e difetti
- L'informazione degli stakeholder circa la qualità dell'oggetto di test in modo che essi possano prendere decisioni ragionate
- La riduzione del rischio che si produca e si rilasci software di qualità inadeguato in ambiente operativo
- Il rispetto dei requisiti in modo che gli standard contrattuali legali vengano rispettati
Qual'è la differenza tra il testing ed il debugging?
Il testing è l'attività che puo' mostrare failure causate da difetti del software.
Il debugging è l'attività che trova, analizza e corregge i difetti trovati dal testing. Dopo il debugging c'è ancora un'attività di testing confermativo che verifica se l'attività di correzione effettuata durante il debug abbia effettivamente risolto il problema evidenziato durante la prima fase di testing.
Perché il Testing è Necessario
Nell'ottica di ridurre il rischio di failure durante il funzionamento di un sistema (che può essere anche vitale se si pensa al software di controllo della velocità di un'auto), occorre testare in modo rigoroso componenti e sistemi software ma anche la documentazione. Ogni volta che si riscontra un difetto e lo si corregge miglioriamo la qualità del software. In determinati settori o per esigenze contrattuali, è una fase indispensabile del processo di produzione stesso.
Esempi del perché il testing è necessario
- Per evitare rilasci in esercizio di software affetto da difetti
- Per prevenire failure in esercizio
- Per essere sicuri che le esigenze degli stakeholder siano soddisfatte
- Per contribuire al successo dello sviluppo
- Per migliorare la manutenzione del software
Relazioni fra testing e quality assurance
La quality assurance (o garanzia della qualità o QA) è correlata al testing ma non è la stessa cosa.
La gestione della qualità all'interno di un'azienda comprende varie attività tra cui la garanzia della qualità e il controllo della qualità.
La garanzia di qualità si raggiunge attraverso l'esecuzione corretta di appositi processi di produzione. Ciò determina un prodotto di qualità superiore e previene difetti di produzione.
Il controllo di qualità comprende anche le attività di testing necessarie al raggiungimento di adeguati livelli di qualità.
Come il testing contribuisce in termini di qualità
Si contribuisce attraverso le attività tipiche del testing. Per citarne alcune:
- Valutazione dei requisiti, delle user story, della progettazione, del codice
- Esecuzione del sistema o del singolo componente per scoprire eventuali failure
- Identificazione del difetto che ha causato la failure attraverso il debugging
Distinzione tra errore, difetto e failure
- L'errore introduce un difetto
- Un difetto può causare una failure
- Una failure è un malfunzionamento
Tutto parte dagli errori che si possono verificare per varie ragioni:
- Vincoli di tempo, ad esempio una stima errata
- L'uomo è infallibile ed è quindi inevitabile l'errore umano
- Il team di sviluppo non è adeguatamente qualificato o è inesperto
- Inadeguata comunicazione tra i partecipanti al progetto
- Complessità del progetto
- Malintesi tra le interfacce tra i vari sistemi che devono interagire
- Tecnologie nuove non ancora adeguatamente conosciute
Ma le failure si possono presentare anche per cause non dovute al codice ma a fattori ambientali
- Radiazioni
- Campi elettromagnetici
- Inquinamento
- Temperatura
I fattori ambientali appena elencati possono modificare le condizioni dell'Hardware causando difetti del Firmware e di conseguenza una failure a livello di Software
Durante la fase di test si possono avere falsi positivi e falsi negativi.
- I falsi positivi sono segnalati come difetti ma in realtà non lo sono
- I falsi negativi sono test che non rilevano i difetti che avrebbero dovuto rilevare
I falsi positivi o negativi possono verificarsi a causa di un errato modo di eseguire il test o a causa di difetti nei dati di test, all'ambiente di test o altri motivi.
Distinzione tra root cause, difetti, ed effetti
- Root Cause: il product owner non ha adeguati skills circa il calcolo degli interessi
- Difetto principale: il product owner scrive una user story ambigua per il calcolo degli interessi
- Difetto: è la riga di codice scritta in base alla user story che determina la failure
- Failure: è in questo esempio il pagamento di interessi errati ai clienti della banca
- Effetti: i clienti si lamentano perché ricevono un errato tasso di interessi.
I sette principi del testing
- Il testing mostra la presenza di difetti ma non può provarne l'assenza. Anche se nessun difetto viene trovato non significa che il software sie privo di difetti.
- Il testing esaustivo è impossibile tranne per casi banali. In questi casi è necessario usare l'analisi del rischio, le tecniche di testing e le priorità per decidere dove concentrare gli sforzi
- Il testing anticipato permette di risparmiare tempo e denaro infatti ciò permette di individuare tempestivamente i difetti (ad ogni livello) aiutando quindi ad evitare modifiche successive in caso di errori che potrebbero essere anche costose e lunghe in base alla gravità.
- I difetti tendono a formare cluster(3) infatti solitamente un numero limitato di moduli è quello che contiene i difetti. Indicazione importante per l'analisi di rischio e per concentrare l'effort del test in modo specifico e mirato.
- Attenzione al paradosso pesticida. Se si usa sempre lo stesso test e sempre la stessa base dati si rischia di non rilevare più difetti. Per tanto è necessario a volte modificare sia la base dati che riprogettare il tipo di test.
- Il testing è dipendente dal contesto. Un software safety-critical viene testato in modo diverso da una app per e-commerce o da un progetto Agile.
- L’assenza di errori è una falsa credenza anche se alcune organizzazioni sperano nel buon lavoro dei tester, ciò è impossibile! Un ottimo lavoro non garantisce comunque il successo di un sistema.
Il Processo di Test
Esistono un insieme di attività tipiche per raggiungere l'obiettivo del test ma non esiste un processo unico ed universale per il testing del software. Il processo di test è definito dalle attività da eseguire. In base a come, quali e quando queste attività sono scelte ed implementate, si determina un adeguato processo di test.
L’impatto del contesto sul processo di test
Il contesto influenza il processo di test. Tra i fattori di contesto che possono determinare il processo di test possiamo elencare i seguenti:
- Il modello di ciclo vita e le metodologie dello sviluppo software
- I livelli di test e i tipi di test adottati
- I rischi sia del prodotto che del progetto
- Il dominio del business
- I vincoli operativi: budget e risorse, tempistiche, complessità, requisiti contrattuali e normativi
- Le politiche e le pratiche organizzative
- Gli standard interni ed esterni richiesti
Sarebbe buona pratica che la base dei test, abbia criteri di copertura definiti e misurabili in modo da poter dimostrare attraverso i KPI (key performace indicator) il raggiungimento degli obiettivi del testing del progetto/sistema software.
Supponiamo di avere una lista di requisiti e una lista di smartphone supportati dall'app che dobbiamo realizzare. Ogni requisito ed ogni smartphone fanno parte della base di test.
I criteri di copertura richiedono, ad esempio, che occorre effettuare almeno un caso di test per ciascun elemento sia requisiti che smartphone in modo da indicare agli stakeholder che i requisiti sono stati soddisfatti e se sugli smartphone sono state riscontrate failure.
Descrivere le attività di testing e i rispettivi compiti nel processo di test
Un processo di test è costituito da vari gruppi di attività. A seguire i gruppi di attività principali:
- Pianificazione dei test
- Monitoraggio e controllo dei test
- Analisi dei test
- Progettazione dei test
- Implementazione dei test
- Esecuzione dei test
- Completamento dei test
L'implementazione delle suddette attività, benché portano a pensare ad una implementazione sequenziale, spesso avviene in maniera iterativa.
Pianificazione dei test
La pianificazione del test comprende tutte le attività che definiscono gli obiettivi del test e l'approccio per soddisfarli nell'ambito del contesto esistente. Ad esempio specificando tecniche e test idonei e schedulando i test per rispettare le scadenze. I piani di test possono essere rivisti in base ai feedback ed alle attività di monitoraggio e controllo.
Monitoraggio e controllo dei test
Il monitoraggio dei test prevede il confronto degli avanzamenti rispetto al piano attraverso le metriche definite dal piano di test.
Il controllo dei test è necessario per poter adottare le azioni necessarie a soddisfare gli obiettivi del piano di test.
Entrambi, monitoraggio e controllo, sono supportati dalle valutazioni dei criteri di uscita.
Un esempio di valutazione dei criteri di uscita in base a risultati e log dei test potrebbe essere:
- Verifica dei risultati rispetto ai criteri di copertura
- Valutazione del livello di qualità del componente o del sistema
- Necessità di avere nuovi test perché i test progettati non hanno raggiunto l'obiettivo
(1) - Esempio di requisito: Il sistema permetterà di prenotare un taxi e di avere una stima del tempo di attesa
(2) - Esempio di una User Story:
Cliente: “Salve Radio City, mi occorre un taxi in via Napoli 1861”
Sistema: “Vesuvio 79 arriverà in 5 minuti”
(3) - Un cluster è un raggruppamento logico
* https://openclipart.org/detail/308849/mental-health
