7 principles software testing
Sette principi del test del software: inclusi ulteriori dettagli sul clustering dei difetti, il principio di Pareto e il paradosso dei pesticidi.
Sono sicuro che tutti siano consapevoli del ' Sette principi di test del software '.
Questi principi di test fondamentali aiutano i team di test a utilizzare il loro tempo e i loro sforzi per rendere efficace il processo di test. In questo articolo, impareremo in dettaglio due principi, ad es. Clustering dei difetti, principio di Pareto e paradosso dei pesticidi .
Cosa imparerai:
- Sette principi di test del software
Sette principi di test del software
Prima di dare uno sguardo approfondito a questi due principi, comprendiamo brevemente i sette principi del test del software.
Esploriamo !!
# 1) Il test mostra la presenza di difetti
Ogni applicazione o prodotto viene rilasciato in produzione dopo una quantità sufficiente di test da parte di diversi team o passa attraverso diverse fasi come il test di integrazione del sistema, il test di accettazione dell'utente e il beta test ecc.
Così hai mai visto o sentito da qualcuno del team di test che hanno testato completamente il software e non ci sono difetti nel software ? Al contrario, ogni team di test conferma che il software soddisfa tutti i requisiti aziendali e funziona secondo le esigenze dell'utente finale.
Nel settore dei test del software, nessuno dirà che esiste nessun difetto nel software, il che è del tutto vero in quanto i test non possono dimostrare che il software sia privo di errori o di difetti.
Tuttavia, l'obiettivo del test è trovare sempre più difetti nascosti utilizzando tecniche e metodi diversi. I test possono rivelare difetti non scoperti e se non vengono rilevati difetti, non significa che il software sia privo di difetti.
Esempio 1 :
Considera un'applicazione bancaria, questa applicazione è accuratamente testata e subisce diverse fasi di test come SIT, UAT ecc. E attualmente non vengono identificati difetti nel sistema.
Tuttavia, potrebbe esserci la possibilità che nell'ambiente di produzione, il cliente reale provi una funzionalità che è usata raramente nel sistema bancario e i tester hanno trascurato quella funzionalità, quindi nessun difetto è stato trovato fino ad oggi o il codice non è mai stato toccato dagli sviluppatori .
Esempio 2:
Abbiamo visto numerose pubblicità di saponi, dentifrici, lavamani o spray disinfettanti ecc. In televisione.
Considera una pubblicità sul lavaggio delle mani che dice alla televisione che il 99% dei germi può essere rimosso se viene utilizzato quel lavaggio a mano specifico. Ciò dimostra chiaramente che il prodotto non è privo di germi al 100%. Pertanto, nel nostro concetto di test, possiamo dire che nessun software è privo di difetti.
# 2) Test precoci
I tester devono essere coinvolti in una fase iniziale del ciclo di vita dello sviluppo del software (SDLC). In questo modo è possibile identificare i difetti durante la fase di analisi dei requisiti o eventuali difetti della documentazione. Il costo relativo alla riparazione di tali difetti è molto inferiore rispetto a quelli riscontrati durante le fasi successive del test.
Considera l'immagine sottostante che mostra come il costo della correzione dei difetti aumenta man mano che i test si spostano verso la produzione dal vivo.
(Immagine fonte )
L'immagine sopra mostra che il costo richiesto per riparare un difetto riscontrato durante l'Analisi dei Requisiti è inferiore e continua ad aumentare man mano che ci si sposta verso la fase di Test o di Manutenzione.
Ora la domanda è quanto presto dovrebbe iniziare il test ?
Una volta finalizzati i requisiti, i tester devono essere coinvolti per i test. I test devono essere eseguiti sui documenti dei requisiti, sulle specifiche o su qualsiasi altro tipo di documento in modo che, se i requisiti sono definiti in modo errato, possono essere risolti immediatamente anziché fissarli nella fase di sviluppo.
# 3) Non è possibile eseguire test esaustivi
Non è possibile testare tutte le funzionalità con tutte le combinazioni valide e non valide di dati di input durante il test effettivo. Invece di questo approccio, il test di alcune combinazioni è considerato basato sulla priorità utilizzando tecniche diverse.
I test esaustivi richiederanno sforzi illimitati e la maggior parte di questi sforzi sono inefficaci. Inoltre, le tempistiche del progetto non consentiranno di testare così tante combinazioni. Pertanto si consiglia di testare i dati di input utilizzando metodi diversi come Partizionamento di equivalenza e Analisi del valore limite.
Per esempio ,Supponiamo di avere un campo di input che accetta solo alfabeti, caratteri speciali e numeri da 0 a 1000. Immagina quante combinazioni apparirebbero per il test, non è possibile testare tutte le combinazioni per ogni tipo di input.
Gli sforzi necessari per eseguire il test saranno enormi e avranno anche un impatto sulla tempistica e sui costi del progetto. Quindi si dice sempre che i test esaustivi non sono praticamente possibili.
# 4) Il test dipende dal contesto
Ci sono diversi domini disponibili sul mercato come banche, assicurazioni, medicina, viaggi, pubblicità ecc. E ogni dominio ha una serie di applicazioni. Inoltre, per ogni dominio, le loro applicazioni hanno requisiti, funzioni, scopi di test diversi, rischi, tecniche, ecc. Diversi.
I diversi domini vengono testati in modo diverso, quindi il test è basato esclusivamente sul contesto del dominio o dell'applicazione.
Per esempio ,testare un'applicazione bancaria è diverso dal testare qualsiasi applicazione di e-commerce o pubblicitaria. Il rischio associato a ciascun tipo di applicazione è diverso, quindi non è efficace utilizzare lo stesso metodo, tecnica e tipo di test per testare tutti i tipi di applicazione.
# 5) Clustering dei difetti
Durante il test, può accadere che la maggior parte dei difetti riscontrati siano legati a un numero limitato di moduli. Potrebbero esserci più ragioni per questo come i moduli potrebbero essere complessi, la codifica relativa a tali moduli potrebbe essere complicata ecc.
Questo è il principio di Pareto del test del software in cui l'80% dei problemi si trova nel 20% dei moduli. Più avanti in questo articolo impareremo di più sul clustering dei difetti e sul principio di Pareto.
# 6) Paradosso dei pesticidi
Il principio del paradosso dei pesticidi afferma che se la stessa serie di casi di test viene eseguita ripetutamente durante il periodo di tempo, questa serie di test non è in grado di identificare nuovi difetti nel sistema.
Per superare questo 'paradosso dei pesticidi', la serie di casi di test deve essere regolarmente rivista e rivista. Se necessario, è possibile aggiungere una nuova serie di casi di test e gli scenari di test esistenti possono essere eliminati se non sono in grado di trovare altri difetti dal sistema.
# 7) Assenza di errore
Se il software viene testato completamente e se non vengono rilevati difetti prima del rilascio, possiamo dire che il software è privo di difetti al 99%. Ma cosa succede se questo software viene testato rispetto a requisiti errati? In questi casi, anche la ricerca di difetti e la loro tempestiva correzione non sarebbe di aiuto in quanto il test viene eseguito su requisiti errati che non corrispondono alle esigenze dell'utente finale.
Per esempio, supponiamo che l'applicazione sia correlata a un sito di e-commerce e che i requisiti per la funzionalità 'Carrello o Carrello' siano interpretati e testati in modo errato. In questo caso, anche la ricerca di più difetti non aiuta a spostare l'applicazione nella fase successiva o nell'ambiente di produzione.
Questi sono i sette principi del test del software.
Ora esploriamo Defect Clustering, Pareto Principle and Pesticide Paradox in dettaglio .
Difetto di clustering
Durante il test di qualsiasi software, i tester si imbattono principalmente in una situazione in cui la maggior parte dei difetti rilevati sono correlati ad alcune funzionalità specifiche e il resto delle funzionalità avrà un numero inferiore di difetti.
Il clustering dei difetti significa un numero limitato di moduli che contengono la maggior parte dei difetti. Fondamentalmente, i difetti non sono distribuiti in modo uniforme nell'intera applicazione, piuttosto i difetti sono concentrati o centralizzati su due o tre funzionalità.
A volte, è possibile a causa della complessità dell'applicazione, la codifica può essere complessa o complicata, uno sviluppatore può commettere un errore che potrebbe influire solo su una funzionalità o un modulo specifico.
Il clustering dei difetti si basa su ' Principio di Pareto ', Noto anche come Regola 80-20 . Significa che l'80% dei difetti riscontrati sono dovuti al 20% dei moduli nell'applicazione. Il concetto di principio di Pareto è stato inizialmente definito da un economista italiano - Vilfrodo Pareto .
Se i tester esaminano 100 difetti, non sarà chiaro se esiste un significato sottostante rispetto a quei 100 difetti. Ma se questi 100 difetti sono classificati in base ad alcuni criteri specifici, è possibile che i tester comprendano che un gran numero di difetti appartengono solo a pochissimi moduli specifici.
Per esempio ,consideriamo l'immagine sottostante che è stata testata per una delle applicazioni bancarie e mostra che la maggior parte dei difetti è correlata alla funzionalità 'Scoperto di conto'. Il resto delle funzionalità come il riepilogo del conto, il trasferimento di fondi, le istruzioni permanenti ecc. Hanno un numero limitato di difetti.
(Immagine fonte )
L'immagine sopra indica che ci sono 18 difetti intorno alla funzionalità Scoperto su un totale di 32 difetti, il che significa che il 60% dei difetti si trova nel modulo 'Scoperto di conto'.
Quindi, i tester si concentrano principalmente su quest'area durante l'esecuzione per trovare sempre più difetti. Si consiglia ai tester di concentrarsi in modo simile anche sugli altri moduli durante il test.
Quando uno stesso codice o modulo viene testato, più e più volte, utilizzando una serie di casi di test rispetto alle iterazioni iniziali, il numero di difetti è elevato, tuttavia, dopo alcune iterazioni, il conteggio dei difetti verrà notevolmente ridotto. Il clustering dei difetti indica che l'area soggetta a difetti deve essere testata accuratamente durante il test di regressione.
Paradosso dei pesticidi
Quando si scopre che uno dei moduli ha più difetti, i tester fanno ulteriori sforzi per testare quel modulo.
Dopo alcune iterazioni di test, la qualità del codice viene migliorata e il conteggio dei difetti inizia a diminuire poiché la maggior parte dei difetti viene risolta dal team di sviluppo poiché gli sviluppatori sono anche cauti durante la codifica di un particolare modulo in cui i tester hanno riscontrato più difetti.
Quindi, a un certo punto, la maggior parte dei difetti viene scoperta e risolta in modo che non vengano trovati nuovi difetti in quel modulo.
Tuttavia, a volte può accadere che, pur essendo estremamente cauti durante la codifica su un particolare modulo (qui nel nostro caso il ' Scoperto 'Modulo), lo sviluppatore può trascurare gli altri moduli per codificarlo correttamente o le modifiche apportate in quel particolare modulo potrebbero avere un impatto negativo su altre funzionalità come Riepilogo conto, Trasferimento di fondi e Istruzioni permanenti.
Quando i tester utilizzano lo stesso set di casi di test per eseguire il modulo in cui si trovano la maggior parte dei difetti (modulo Overdraft), dopo aver risolto quei difetti dagli sviluppatori, questi casi di test non sono molto efficaci per trovare nuovi difetti. Come flusso end-to-end dello scoperto, il modulo viene testato accuratamente e gli sviluppatori hanno anche scritto il codice per quel modulo con cautela.
È necessario rivedere e aggiornare questi casi di test. È anche una buona idea aggiungere nuovi casi di test in modo che nuovi e più difetti possano essere trovati in diverse aree del software o dell'applicazione.
Metodi preventivi del paradosso dei pesticidi
Ci sono due opzioni attraverso le quali possiamo prevenire il paradosso dei pesticidi come mostrato di seguito:
per) Scrivere una nuova serie di casi di test che si concentreranno su aree o moduli diversi (diversi dal precedente modulo soggetto a difetti - Esempio: 'Scoperto di conto') del software.
b) Preparare nuovi casi di test e aggiungerli a quelli esistenti.
Nel ' metodo A ', I tester possono trovare più difetti negli altri moduli in cui non erano concentrati durante i test precedenti o gli sviluppatori non sono stati particolarmente cauti durante la codifica.
Nel nostro esempio sopra, i tester possono trovare più difetti nei moduli Riepilogo account, Trasferimento fondi o Istruzioni permanenti utilizzando la nuova serie di casi di test.
Ma può accadere che i tester trascurino il modulo precedente ( Esempio: 'Scoperto di conto') dove la maggior parte dei difetti sono stati trovati nella precedente iterazione e questo potrebbe essere un rischio in quanto questo modulo (Scoperto di conto) potrebbe essere stato iniettato con i nuovi difetti dopo la codifica degli altri moduli.
Nel ' metodo B ', Vengono preparati nuovi casi di test in modo che nuovi potenziali difetti possano essere trovati nel resto dei moduli.
Nel nostro esempio, i casi di test di nuova creazione saranno in grado di aiutare a identificare i difetti nei moduli come Riepilogo account, Trasferimento di fondi e Istruzione permanente. Tuttavia, i tester non possono ignorare i precedenti moduli soggetti a difetti ( Esempio: 'Scoperto di conto') poiché questi nuovi casi di test vengono uniti ai casi di test esistenti.
I casi di test esistenti erano più focalizzati sul modulo 'Scoperto di conto' e i nuovi casi di test erano focalizzati sugli altri moduli. Quindi tutti i set di casi di test vengono eseguiti almeno una volta che si verifica anche una modifica del codice su qualsiasi modulo. Ciò garantirà che venga eseguita la regressione corretta e che il difetto possa essere identificato a causa di questa modifica del codice.
Utilizzando il secondo approccio, il conteggio totale dei casi di test aumenta in modo significativo e si traduce in maggiori sforzi e tempo necessari per l'esecuzione. Ciò ovviamente avrà un impatto sulle scadenze del progetto e, soprattutto, sul budget del progetto.
Quindi, per superare questo problema, i casi di test ridondanti possono essere rivisti e quindi rimossi. Ci sono molti casi di test che diventano inutili dopo l'aggiunta di nuovi casi di test e la modifica di quelli esistenti.
È necessario verificare quali casi di test non sono riusciti per identificare i difetti nelle ultime 5 iterazioni (supponiamo 5 iterazioni) e quali casi di test non sono molto importanti. Può anche accadere che il flusso singolo coperto in alcuni casi di test possa essere coperto in un altro caso di test end-to-end e quei casi di test che hanno un flusso singolo possano essere rimossi.
Questo, a sua volta, ridurrà il conteggio totale dei casi di test.
Per esempio ,abbiamo 50 casi di test per coprire un modulo particolare e abbiamo visto che di questi 50 casi di test 20 casi di test non sono riusciti a rilevare un nuovo difetto nelle ultime iterazioni di test (supponiamo 5 iterazioni). Quindi questi 20 casi di test devono essere esaminati accuratamente e dobbiamo verificare quanto sono importanti questi casi di test e di conseguenza può essere presa una decisione se mantenere i 20 casi di test o rimuoverli.
Prima di rimuovere qualsiasi test case, verificare che il flusso di funzionalità coperto in quei test case sia coperto da un altro test case. Questo processo deve essere seguito in tutti i moduli in modo che il numero totale di casi di test venga ridotto in modo significativo. Ciò garantirà che il conteggio totale dei casi di test sia ridotto ma che vi sia ancora una copertura dei requisiti del 100%.
Significa che tutti i restanti casi di test coprono tutti i requisiti aziendali, quindi non vi è alcun compromesso sulla qualità.
Conclusione
Il test del software è un passaggio essenziale in SDLC in quanto verifica se il software funziona secondo le esigenze dell'utente finale o meno.
Il test identifica il maggior numero di difetti possibile. Quindi, al fine di eseguire i test in modo efficace ed efficiente, tutti dovrebbero essere consapevoli e effettivamente comprendere i sette principi del test del software chiaramente e sono noti come i pilastri del test.
La maggior parte dei tester ha implementato e sperimentato questi principi durante i test effettivi.
domande e risposte all'intervista per ingegneri addetti all'assicurazione della qualità
In generale, il termine principio indica le regole o le leggi che devono essere seguite. Quindi, tutti nel settore del test del software devono seguire questi sette principi e se qualcuno ignora qualcuno di questi principi, potrebbe costare enormemente al progetto.
Buona lettura!!
Lettura consigliata
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Lavoro assistente QA test software
- Corso di test del software: quale istituto di test del software dovrei iscrivermi?
- Scegliere il test del software come carriera
- Lavoro freelance di scrittore di contenuti tecnici di test del software
- Che cos'è la tecnica di test basata sui difetti?
- Alcune interessanti domande di intervista sul test del software
- Feedback e recensioni sul corso di test del software