Questo tutorial introduce i sette principi di base del test del software che ogni tester del software e professionista del controllo qualità dovrebbe conoscere.
7 Principi di test del software
- I test mostrano la presenza di difetti
- Non sono possibili test esaustivi
- Test precoci
- Difetto di clustering
- Paradosso dei pesticidi
- Il test dipende dal contesto
- Assenza di errori fallaci
Impariamo i principi del test con il seguente video di esempio:
Fare clic qui se il video non è accessibile
sfondo
È importante ottenere risultati di test ottimali durante l'esecuzione di test del software senza deviare dall'obiettivo. Ma come stabilisci che stai seguendo la giusta strategia per i test? Per questo, è necessario attenersi ad alcuni principi di test di base. Di seguito sono riportati i sette principi di test comuni ampiamente praticati nell'industria 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 ai soliti scenari, puoi anche testare le seguenti condizioni
- Tentativo di spostare il file quando è aperto
- Non disponi dei diritti di protezione 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 ha già un file con lo stesso nome, infatti l'elenco è infinito
- Oppure supponi di avere 15 campi di input da testare, ciascuno con 5 valori possibili, il numero di combinazioni da testare sarebbe 5 15
Se si testassero tutte le possibili combinazioni del progetto TEMPI E COSTI DI ESECUZIONE 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 sono possibili test esaustivi. Invece, abbiamo bisogno della quantità ottimale di test in base alla valutazione del rischio dell'applicazione.
E la domanda da un milione di dollari è: come si determina questo rischio?
Per rispondere a questo, facciamo un esercizio
Secondo te, quale operazione potrebbe causare il malfunzionamento del tuo sistema operativo?
Sono sicuro che la maggior parte di voi avrebbe indovinato, aprendo contemporaneamente 10 diverse applicazioni.
Quindi, se steste testando questo sistema operativo, vi rendereste conto che è probabile che si riscontrino difetti nell'attività multi-tasking e che devono essere testati a fondo, il che ci porta al nostro prossimo principio di clustering dei difetti
2) Clustering dei difetti
Defect Clustering che afferma che un piccolo numero di moduli contiene la maggior parte dei difetti rilevati. Questa è l'applicazione del principio di Pareto al test del software: circa l'80% dei problemi si trova 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'allevamento porterà nel tempo agli insetti a sviluppare una resistenza al pesticida, quindi inefficace dei pesticidi sugli insetti. Lo stesso vale per il test del software. Se viene condotta la stessa serie di test ripetitivi, il metodo sarà inutile per scoprire nuovi difetti.
Per ovviare a questo, i casi di test devono essere regolarmente rivisti e rivisti, aggiungendo nuovi e diversi casi di test per aiutare a trovare più difetti.
I tester non possono semplicemente dipendere 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 puoi mai affermare che il tuo prodotto è privo di bug. Per portare a casa 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 rischierebbe la propria reputazione solo per vedere il proprio sistema operativo andare in crash durante il suo lancio pubblico!
4) Il test mostra la presenza di difetti
Quindi, il principio del test afferma che: Il test parla della presenza di difetti e non parla dell'assenza di difetti. Ad esempio, il test del software riduce la probabilità che i difetti non scoperti rimangano nel software, ma anche se non vengono rilevati difetti, non è una prova di correttezza.
Ma cosa succede se, lavori più duramente, prendendo tutte le precauzioni e rendi 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 prossimo principio, che afferma che: assenza di errore
5) Assenza di errore - errore
È possibile che il software privo di bug al 99% sia ancora inutilizzabile. Questo può essere il caso se il sistema viene testato accuratamente per il requisito sbagliato. Il test del software non è solo la ricerca di difetti, ma anche per verificare che il software soddisfi le esigenze aziendali. L'assenza di errore è un errore, ovvero trovare e correggere i difetti non aiuta se la build del sistema è inutilizzabile e non soddisfa le esigenze e i requisiti dell'utente.
Per risolvere questo problema, il prossimo principio di test afferma che Early Testing
6) Test precoci
Test precoce: il test dovrebbe iniziare il prima possibile nel ciclo di vita dello sviluppo del software. In modo che eventuali difetti nei requisiti o nella fase di progettazione vengano rilevati nelle prime fasi. È molto più economico riparare un difetto nelle prime fasi del 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 successivo tutorial di formazione.
7) Il test dipende dal contesto
Il test dipende dal contesto, il che significa fondamentalmente che il modo in cui testate un sito di e-commerce sarà diverso dal modo in cui testate un'applicazione commerciale pronta all'uso. Tutti i software sviluppati non sono identici. È possibile utilizzare un approccio, metodologie, tecniche e tipi di test diversi a seconda del tipo di applicazione. Ad esempio, il test, qualsiasi sistema POS in un negozio al dettaglio sarà diverso dal test di un bancomat.
Mito: "I principi sono solo per riferimento. Non li userò nella pratica."
Questo è molto falso. I Principi del test ti aiuteranno a creare una strategia di test efficace e a creare bozze di casi di test per la cattura degli errori.
Ma apprendere i principi dei test è proprio 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 intrattenere conversazioni con altri passeggeri in macchina.
Lo stesso vale per i principi di test. I tester esperti hanno interiorizzato questi principi a un livello tale da applicarli anche senza pensare. Quindi il mito che i principi non siano usati nella pratica è semplicemente falso.