7 Principi di test del software con esempi

Questo tutorial introduce i sette principi base del test del software che ogni tester del software e professionista del controllo qualità dovrebbe conoscere.

Impariamo i principi di test con quanto segue Esempio video-

Clicchi qui se il video non è accessibile

sfondo

È importante ottenere risultati di test ottimali durante l'esecuzione di test software senza discostarsi dall'obiettivo. Ma come si determina se si sta seguendo la strategia giusta per i test? Per questo, è necessario attenersi ad alcuni principi di test di base. Ecco i sette principi di test comuni ampiamente praticati nel settore del software.

Per capirlo, considera uno scenario in cui stai spostando un file dalla cartella A alla cartella B.

Pensa a tutti i modi possibili per testarlo.

Oltre agli scenari usuali, puoi anche testare le seguenti condizioni

• Tentativo di spostare il file quando è aperto
• Non disponi dei diritti di sicurezza per incollare il file nella cartella B
• La cartella B si trova su un'unità condivisa e la capacità di archiviazione è piena.
• La cartella B contiene già un file con lo stesso nome, infatti l'elenco è infinito
• Oppure supponiamo di avere 15 campi di input da testare, ciascuno con 5 valori possibili, il numero di combinazioni da testare sarebbe 5 ^ 15

Se dovessi testare tutte le possibili combinazioni, TEMPI E COSTI DI ESECUZIONE del progetto aumenterebbero in modo esponenziale. Abbiamo bisogno di determinati principi e strategie per ottimizzare lo sforzo di test

Ecco i 7 principi:

1) Non è possibile eseguire test esaustivi

SÌ! Non è possibile eseguire test esaustivi. Abbiamo invece bisogno della quantità ottimale di test basata sulla valutazione del rischio dell'applicazione.

E la domanda da un milione di dollari è: come si determina questo rischio?

Per rispondere facciamo un esercizio

Secondo te, quale operazione ha maggiori probabilità di causare il tuo Operasistema fallisce?

Sono sicuro che molti di voi avrebbero immaginato di aprire 10 applicazioni diverse contemporaneamente.

Quindi se stavi testando questo Operating, ti renderesti conto che è probabile che si trovino dei difetti nell'attività multi-tasking e che debbano essere testati a fondo, il che ci porta al nostro principio successivo Difetto ClusterING

2) Difetto ClusterING

Difetto Clustering che afferma che un numero limitato di moduli contiene la maggior parte dei difetti rilevati. Questa è l'applicazione del Principio di Pareto al testing del software: circa l'80% dei problemi si riscontrano nel 20% dei moduli.

Per esperienza, puoi identificare tali moduli rischiosi. Ma questo approccio ha i suoi problemi

Se gli stessi test vengono ripetuti più e più volte, alla fine gli stessi casi di test non troveranno più nuovi bug.

3) Paradosso dei pesticidi

L'uso ripetitivo della stessa miscela di pesticidi per sradicare gli insetti durante l'agricoltura porterà nel tempo gli insetti a sviluppare resistenza al pesticida. Pertanto, i pesticidi saranno inefficaci sugli insetti. Lo stesso vale per i test del software. Se viene condotta la stessa serie di test ripetitivi, il metodo sarà inutile per scoprire nuovi difetti.

Per superare questo problema, i casi di test devono essere regolarmente rivisti e revisionati, aggiungendo casi di test nuovi e diversi per aiutare a trovare più difetti.

I tester non possono dipendere semplicemente dalle tecniche di test esistenti. Deve cercare continuamente di migliorare i metodi esistenti per rendere i test più efficaci. Ma anche dopo tutto questo sudore e duro lavoro nei test, non potrai mai affermare che il tuo prodotto sia privo di bug. Per ribadire questo punto, vediamo questo video del lancio pubblico di Windows 98

Pensi che un'azienda come MICROSOFT non avrebbe testato a fondo il proprio sistema operativo e avrebbe messo a rischio la propria reputazione solo per vedere il proprio sistema operativo bloccarsi durante il lancio pubblico!

4) Il test mostra la presenza di difetti

Pertanto, il principio di test afferma che: il test parla della presenza di difetti e non parla dell'assenza di difetti. Software Testing riduce la probabilità che rimangano difetti non scoperti nel software ma, anche se non vengono rilevati difetti, non è una prova di correttezza.

Ma cosa succede se lavori molto duramente, prendendo tutte le precauzioni e rendendo il tuo prodotto software privo di bug al 99%. E il software non soddisfa le esigenze e i requisiti dei clienti.

Questo ci porta al nostro principio successivo, che afferma che: Assenza di errore

5) Assenza di errore – errore

È possibile che un software privo di bug al 99% sia ancora inutilizzabile. Questo può accadere se il sistema viene testato a fondo per individuare il requisito sbagliato. Il test del software non consiste semplicemente nel trovare difetti, ma anche nel verificare che il software soddisfi le esigenze aziendali. L'assenza di errori è un errore, ovvero trovare e correggere i difetti non aiuta se la creazione del sistema è inutilizzabile e non soddisfa le esigenze e i requisiti dell'utente.

Per risolvere questo problema, il successivo principio del test afferma che Early Testing

6) Test anticipati

Test anticipati: i test dovrebbero iniziare il prima possibile nel ciclo di vita dello sviluppo software. In modo che eventuali difetti nei requisiti o nella fase di progettazione vengano rilevati nelle fasi iniziali. È molto più economico correggere un difetto nelle fasi iniziali dei test. Ma quanto presto si dovrebbe iniziare a testare? Si consiglia di iniziare a trovare il bug nel momento in cui vengono definiti i requisiti. Maggiori informazioni su questo principio in un tutorial di formazione successivo.

7) Il test dipende dal contesto

Il test dipende dal contesto, il che significa sostanzialmente che il modo in cui testi un sito di e-commerce sarà diverso dal modo in cui testi un'applicazione commerciale standard. Tutti i software sviluppati non sono identici. Potresti utilizzare un approccio, metodologie, tecniche e tipi di test diversi a seconda del tipo di applicazione. Ad esempio, testare qualsiasi sistema POS in un negozio al dettaglio sarà diverso dal testare un bancomat.

Mito: “I principi sono solo di riferimento. Non li userò nella pratica.”

Questo è assolutamente falso. I principi del test ti aiuteranno a creare un test efficace Strategia di prova e bozza di casi di test per l'individuazione degli errori.

Ma apprendere i principi dei test è come imparare a guidare per la prima volta.

Inizialmente, mentre impari a guidare, presti attenzione a tutto, come i cambi di marcia, la velocità, la gestione della frizione, ecc. Ma con l'esperienza, ti concentri solo sulla guida, il resto viene naturale. In modo tale da poter conversare anche con gli altri passeggeri dell'auto.

Lo stesso vale per i principi di test. I tester esperti hanno interiorizzato questi principi a un livello tale da applicarli anche senza pensarci. Quindi il mito secondo cui i principi non vengono utilizzati nella pratica semplicemente non è vero.