Strategia ed organizzazione dei test software (Testing standards)

Nello svolgere le attività relative al test software si possono utilizzare diversi metodi, che coinvolgono tecniche e strumenti di supporto. La scelta dei metodi, tecniche e strumenti porta a definire una strategia, che è appunto l’elemento qualificante per ottenere risultati adeguati.
Lo standard di documentazione del Piano di test offre uno spazio di primo piano alla “Strategia ed organizzazione dei test”, considerando tale aspetto determinante e troppo spesso non sufficientemente considerato.

Un altro elemento previsto è l’evidenza dei criteri e strumenti previsti per la progettazione, predisposizione e ripristino della base dati di test, sulla base delle informazioni di progettazione di dettaglio dei test (precondizioni), descrivendo con esattezza le modalità di generazione, estrazione e comparazione, nonché di mascheramento (data privacy) nel caso di utilizzo di dati reali e sensibili.

La struttura dei template per la progettazione di alto livello (tabella dei test) e di dettaglio (script di test) è stata affinata per garantire il massimo dei risultati con il minor sforzo. Essi consentono e guidano nell’utilizzo delle tecniche di pianificazione e progettazione del test, che dovranno essere utilizzate per garantire una adeguata copertura degli obiettivi di verifica e di validazione, intesi rispettivamente per la ricerca di anomalie nel software realizzato e conformità ai requisiti espressi.

A tal fine possono essere utili le seguenti indicazioni:

1. I test, come le funzionalità / requisiti collegati, sono classificati per livello di esposizione al rischio (valutazione di probabilità e impatto di un evento negativo in esercizio).
2. I test sono pianificati secondo cicli di esecuzione, in modo da conoscere il loro miglior utilizzo nell’economia del processo (ad esempio alcuni test sono idonei a soddisfare un primo “giro esplorativo”, per validare l’installazione nell’ambiente di prova e il funzionamento generale dell’applicazione, altri test sono invece adatti alla validazione dei requisiti utente e accettazione, come ad esempio i test derivati dagli scenari dei casi d’uso).
3. Sulle funzionalità elementari e funzionalità utente sono applicabili, ad esempio, le tecniche di partizionamento delle classi di equivalenza (tecniche blackbox), per determinare le condizioni positive e negative da sottoporre a verifica.
4. Gli scenari dei casi d’uso diventano importanti basi di partenza per identificare gli scenari di test e di integrazione con i quali validare i requisiti stessi (conformità).
5. I requisiti non funzionali sono la base per i test non funzionali, con la possibilità di riportare questi test anche sotto le funzionalità (funzionalità elementare, utente o macro), in quanto con esse si può verificare la rispondenza a quel particolare requisito non funzionale.

Standard test e qualità dei test

Uno degli scopi dello standard introdotto è consentire la massima qualità nella progettazione dei test con il minimo sforzo. Il template è infatti curato e assistito da funzioni automatiche, nonché dagli strumenti, al fine di ridurre al minimo la manualità e la ridondanza delle informazioni. Lo scopo è consentire al progettista maggior tempo e attenzione alla qualità della progettazione, ai dati e alle condizioni di test da realizzare e descrivere, sia ad alto livello sia a livello di dettaglio (script di test).
Poiché è impossibile il test esaustivo, occorre pianificare i test secondo criteri di efficienza ed economicità, di valutazione del rischio e ottimizzando i test in tutte le fasi previste (progettazione e progettazione di dettaglio, esecuzione e automazione).

Nel valutare la qualità dei casi di test è opportuno considerare quattro caratteristiche:

1. l’efficacia, ossia la capacità di rilevare i difetti;
2. l’esemplarità, ossia la capacità di rappresentare in un solo caso di test situazioni differenti;
3. l’economicità, ossia la capacità di realizzare con il minore sforzo economico un caso di test nella sua progettazione, esecuzione ed analisi;
4. l’evolvibilità, ossia la facilità di adeguare un caso di test rispetto alle modifiche apportate al software.

La figura seguente mostra un diagramma Keviat con le quattro caratteristiche fondamendamentali appena descritte. Più alti sono i valori sugli assi, più grande sarà l’area delimitata dai punti di incontro e quindi la qualità del caso di test.