Quali sono i 7 principi del testing software

Perché il Testing è Necessario?

Un testing rigoroso dei componenti e sistemi, inclusa la relativa documentazione associata, può aiutare a ridurre il rischio che si verifichino failure in produzione. Quando i difetti vengono rilevati, e successivamente corretti, questo contribuisce alla qualità dei componenti o dei sistemi. Inoltre, il testing del software può anche essere richiesto per soddisfare requisiti contrattuali o legali, oppure standard specifici in ambito industriale.

Contributi del Testing al Successo

In ambito informatico è abbastanza frequente rilevare situazioni in cui il software e i sistemi siano rilasciati in esercizio e che a valle di tale rilasci, a causa della presenza di difetti, si osservino dei failure o non siano soddisfatte le richieste degli stakeholder. Tuttavia, utilizzando opportune tecniche di test, si è in grado di ridurre la frequenza di tali rilasci problematici, specialmente quando queste tecniche sono applicate con il livello adeguato di competenza nel testing, nei livelli di test appropriati e nei giusti punti del ciclo di vita dello sviluppo software. Ad esempio:

• Avere tester coinvolti nelle review dei requisiti o nel perfezionamento delle user story potrebbe consentire di rilevare difetti in questi prodotti di lavoro. L’identificazione e la correzione dei difetti nei requisiti riduce il rischio di implementare funzionalità errate o non testabili.
• Avere tester che lavorano a stretto contatto con i progettisti di sistema durante la fase di progettazione, può aumentare la reciproca comprensione della progettazione e di come Questa migliore comprensione può ridurre il rischio di difetti di progettazione e permettere di identificare i test in anticipo.
• Avere tester che lavorano a stretto contatto con gli sviluppatori durante lo sviluppo del codice, può aumentare la reciproca comprensione del codice e di come testarlo. Questa migliore comprensione può ridurre il rischio di introdurre difetti nel codice e nei test.
• Avere tester che verificano e validano il software prima del rilascio può consentire di rilevare failure che potrebbero altrimenti essere trascurati, e supporta il processo di eliminare i difetti che hanno causato i failure (ad es. il debugging). Questo aumenta la probabilità che il software soddisfi i requisiti e le esigenze degli stakeholder.

Oltre a questi esempi, il raggiungimento degli obiettivi di test definiti contribuisce al successo complessivo dello sviluppo e della manutenzione del software.

I 7 Principi del Testing

Negli ultimi 50 anni sono stati suggeriti vari principi sul testing che offrono linee guida generali per tutto il testing.

Principio 1 – Il testing mostra la presenza di difetti, non la loro assenza

Il testing può mostrare la presenza di difetti, ma non può provarne l’assenza. Il testing riduce la probabilità che difetti non rilevati rimangano nel software ma, anche se nessun difetto viene trovato, il testing non è una prova di correttezza, ovvero di assenza di difetti.

Principio 2 – Il testing esaustivo è impossibile

Testare tutto (tutte le combinazioni di input e precondizioni) non è fattibile tranne che per casi triviali. Piuttosto che tentare di testare in modo esaustivo, l’analisi del rischio, le tecniche di test e le priorità dovrebbero essere utilizzate per focalizzare l’effort del testing.

Principio 3 – Il testing anticipato permette di risparmiare tempo e denaro

Per trovare i difetti in anticipo, è necessario iniziare attività di test statico e dinamico il prima possibile nel ciclo di vita dello sviluppo software. Il testing anticipato è a volte indicato come “shift left”. Eseguire il test all’inizio del ciclo di vita dello sviluppo software aiuta a ridurre o eliminare le costose modifiche successive.

Principio 4 – I difetti tendono a formare cluster

Un piccolo numero di moduli solitamente contiene la maggior parte dei difetti scoperti durante i test prima del rilascio, o è responsabile della maggior parte dei failure in esercizio. I cluster dei difetti previsti e quelli effettivamente osservati in fase di test o in esercizio sono un input importante a un’analisi del rischio utilizzata per focalizzare l’effort del testing.

Principio 5 – Attenzione al paradosso pesticida

Se gli stessi test vengono ripetuti più e più volte, presumibilmente tali test non rileveranno ulteriori nuovi difetti. Per rilevare nuovi difetti, i test esistenti e i dati di test potrebbero dover essere modificati, e potrebbe essere necessario progettare nuovi test (i test non sono più efficaci nel rilevare difetti, proprio come i pesticidi non risultano più efficaci nell’uccidere gli insetti dopo un utilizzo protratto nel tempo). In alcuni casi, come nei regression test automatizzati, il paradosso pesticida ha un risultato favorevole, che consiste in un numero relativamente basso di difetti di regressione.

Principio 6 – Il testing è dipendente dal contesto

Il testing viene eseguito in modo differente in contesti differenti. Ad esempio, Il test di un software di controllo industriale safety-critical è differente da quello svolto per una app mobile di e-commerce. Come altro esempio, il testing in un progetto Agile viene svolto in modo diverso rispetto al testing in un progetto con ciclo di vita dello sviluppo software sequenziale.

Principio 7 – L’assenza di errori è una falsa credenza

Alcune organizzazioni si aspettano che i tester possano eseguire tutti i test possibili e trovare tutti i difetti possibili, ma i principi 2 e 1 ci dicono, rispettivamente, che questo è impossibile. Inoltre, è una falsa credenza aspettarsi che il solo trovare e risolvere un gran numero di difetti garantisca il successo di un sistema. Ad esempio, eseguire il testing accurato di tutti i requisiti specificati e correggere tutti i difetti rilevati potrebbe comunque non essere sufficiente ad evitare che venga rilasciato un sistema difficile da usare, che non soddisfi le necessità e le aspettative degli utenti, o che risulti inferiore rispetto ad altri sistemi competitivi.