Quando interrompere il test (criteri di uscita nel test del software)

when stop testing

Criteri di uscita in Test:

'Chi ben comincia è a metà dell'opera' - Si applica ovunque, anche per i test del software.

Spesso vediamo i tester del software molto entusiasti all'inizio del progetto. Noi creiamo documenti di prova come Test Strategy, Test Plan o Test Case con entusiasmo ed entusiasmo.

Quindi arriviamo a testare il software con un BANG! Questo è solo amplificato dagli interessanti difetti che troviamo all'inizio del progetto. Farli risolvere non farà che aumentare il nostro risultato.

Quando troviamo un sacco di difetti e completiamo la prima manche, passiamo alla fase successiva. Quando arriviamo alla seconda manche ci rilassiamo e come è la tendenza umana generale annoiarsi a provare la stessa cosa nella seconda manche.

come restituire un array di stringhe in java

Molti tester ritengono che lo sia lavoro monotono nelle esecuzioni successive e iniziare a perdere interesse nel testare lo stesso software più e più volte. Quando arriviamo a, forse la terza esecuzione, una domanda inizia a perseguitarci ed è 'Quando smettere di testare il software?'

Scommetto che devi esserti sentito allo stesso modo e aver chiesto, 'Quando smettere di testare?', Almeno una volta. Direi che la domanda è 'Quando, dove e come interrompere il test?' :)

Concettualmente abbiamo letto e molti tester ritengono che non possa esserci una condizione o un'equazione specifica per decidere 'Quando interrompere il test?' Ci sono una serie di fattori da considerare prima di concludere su questa domanda.

Nell'articolo di oggi, vorrei condividere i miei pensieri su come concludere le attività di test quando arriviamo a un punto del nostro ciclo di test in cui possiamo dire che questo test è sufficiente. Lo faremo con l'aiuto di alcuni esempi di vita reale in un tipico ciclo di test.

Cosa imparerai:

• Quando sono sufficienti i test?
• Fermarsi quando vengono rilevati tutti i difetti: è possibile?
• Decisione di interrompere il test: criteri di uscita
• Che cosa sono i criteri di completamento o di uscita?
• Cosa dovrebbe essere presente nei criteri di uscita?
• Il test può essere interrotto quando:
• Conclusione:
• Lettura consigliata

Quando sono sufficienti i test?

Quando possiamo dire che questo tanto test è sufficiente? I test possono mai essere completati?

Per rispondere a queste domande, dovremo analizzare le attività di test dall'inizio alla fine. Si prega di notare che - definirò queste attività in termini di laico - Non in modo tecnico di fantasia.

Considera che stai iniziando a testare un nuovo progetto.

Attività iniziali:

• Il team di test riceve i requisiti.
• Inizia il team di test pianificazione e progettare.
• I documenti del test iniziale sono pronti e revisionati.

Prova n. 1)

• Il team di test avvia l'esecuzione del test una volta ricevuto il prodotto sviluppato.
• Durante la fase di test, eseguono vari scenari per rompere il software e trovare molti difetti. (Inoltre, il tasso di difetti qui è più alto perché l'applicazione è nuova ed è in fase di valutazione per la prima volta.)
• I difetti vengono corretti dagli sviluppatori e restituiti al team di test per un nuovo test.
• Il team di test esegue nuovamente il test dei difetti ed esegue la regressione.
• Una volta risolti la maggior parte dei difetti di gravità elevata e il software sembra stabile, il team di sviluppo rilascia la prossima versione.

Prova di esecuzione n. 2)

• Il team di test avvia la seconda esecuzione di test e attività simili vengono eseguite come Esecuzione 1.
• In questo processo durante la seconda esecuzione di test, vengono rilevati pochi difetti in più.
• I difetti vengono corretti dagli sviluppatori e restituiti al team di test per un nuovo test.
• Il team di test verifica nuovamente i difetti ed esegue regressione .

Questo può continuare per sempre. Esegui 3, Esegui 4 in poi finché non vengono rilevati tutti i difetti nel software e il software diventa privo di bug.

Se vogliamo disegnare un diagramma di flusso per queste attività, apparirà più o meno come di seguito:

Dal diagramma di flusso sopra, possiamo chiaramente concludere che il test può continuare fino a quando non vengono rilevati tutti i difetti nel software.

Ma la domanda è: è possibile trovare ogni singolo difetto nel software? Proviamo a trovare la risposta a questa domanda da un milione di dollari :).

Fermarsi quando vengono rilevati tutti i difetti: è possibile?

La maggior parte del software è complessa e ha un enorme ambito di test. Non è impossibile trovare tutti i difetti nel software, ma ci vorrà un'eternità.

Anche dopo aver trovato molti bug nel software, nessuno può effettivamente garantire che il software sia privo di difetti ora. Non può esserci una situazione in cui possiamo affermare con sicurezza di aver completato il test, trovato tutti i difetti nel software e non ha più bug.

Inoltre, lo scopo del test non è trovare ogni difetto nel software. Lo scopo del test del software è dimostrare che il software funziona come previsto interrompendolo o trovando una deviazione tra il suo comportamento corrente e il comportamento previsto.

Ci sono difetti illimitati nel software e quindi non è pratico testarlo finché non vengono trovati tutti i difetti poiché non possiamo mai sapere quale sia l'ultimo difetto. La verità è che non possiamo dipendere dalla ricerca di tutti i difetti nel software per concludere i nostri test.

Onestamente, i test sono infiniti e i cicli di test continueranno fino a quando non verrà presa una decisione su quando e dove fermarsi. Ora diventa ancora più complicato decidere di interrompere i test. Se 'fermarsi quando vengono rilevati tutti i difetti' non è il criterio per interrompere il test, su quale base dovrebbe essere deciso?

Decisione di interrompere il test: Criteri di uscita

Proviamo ora a capire: quali sono i fattori più importanti da considerare durante la conclusione delle attività di test? Ritengo che la decisione di interrompere il test dipenda principalmente da Tempo, budget ed estensione del test.

L'approccio più comune è fermarsi quando il tempo / budget è esaurito o tutti gli scenari di test sono stati eseguiti. Tuttavia, con questo approccio, comprometteremo la qualità dei test e ciò non darà sufficiente fiducia sul software; Come?

Vediamo con unesempio.

Scenario di prova:

Supponiamo che tu stia testando un modulo software. Ti è stato assegnato un certo budget per coprirlo. Le tempistiche del progetto sono per un mese. Gli scenari di test totali sono 200. Sei l'unico a provare questo modulo.

Scenario 1)

Settimana 1: Trovi il difetto showstopper / gravità 1 il giorno 1 e l'intero test viene bloccato per 3 giorni. Pertanto non è possibile eseguire nessuno degli scenari finché il difetto di gravità 1 non viene risolto. Dopo aver perso 3 giorni, il blocco viene risolto e tu continui con la tua esecuzione.

Alla fine della settimana, completi 20 scenari con pochi più alti importanti difetti prioritari .

Settimana 2: Inizi a testare il software concentrandoti maggiormente sulla ricerca dei difetti. Durante la seconda settimana si aprono altri difetti di Gravità 1, Gravità 2 e Gravità 3 e alla fine della settimana si sono in grado di coprire 70 scenari.

Terza settimana: All'inizio del 3^rdsettimana in cui vengono risolti tutti i difetti ad alta priorità, quindi insieme all'esecuzione di scenari in sospeso ora è necessario ritestare tutti i difetti che sono finiti nel bucket di test. Continuando con il buon progresso si coprono 120 scenari con difetti aggiuntivi.

A questo punto tutti i difetti ad alta priorità sono già stati trovati e segnalati. Quindi, ora ti rimangono solo i difetti di Gravità 3 da trovare.

Settimana 4: Entro la settimana 4 è necessario ripetere il test della maggior parte dei difetti aperti e dei restanti 80 scenari. Con questo entro la fine della settimana 4, sarai in grado di completare fino a 180 scenari con tutti i difetti di priorità alta e media corretti e riesaminati.

Inserendo queste informazioni in forma tabulare:

Dovresti fermarti qui?

Il motivo per cui ti sei esaurito Testare completamente il tempo e hanno segnalato e risolto la maggior parte dei difetti ad alta priorità. Fermarsi a questo punto ti darà fiducia sul software? Non proprio per i seguenti motivi:

esempi di analisi della causa principale sviluppo di software

• Gli scenari non vengono eseguiti completamente.
• Pochi flussi non vengono nemmeno testati una volta.
• Tutti gli scenari coperti vengono eseguiti una sola volta.
• Il software presenta ancora difetti.
• La regressione non è coperta.

Scenario n. 2)

Settimana 1: Trovi un difetto di gravità 1 il giorno 1 e il test completo viene bloccato per 3 giorni. Pertanto non è possibile eseguire nessuno degli scenari finché il difetto di gravità 1 non viene risolto. Dopo aver perso 3 giorni il blocco viene risolto e tu continui con la tua esecuzione.

Alla fine della settimana, completi 20 scenari con pochi difetti in più. Questa settimana rimane la stessa dello scenario 1.

Settimana 2: Durante la seconda settimana si aprono altri difetti di gravità 1, gravità 2 e gravità 3, ma l'obiettivo è quello di coprire più scenari per coprire il backlog dalla settimana 1. Alla fine della settimana, si è in grado di coprire 120 scenari.

Terza settimana: All'inizio del 3^rdsettimana in cui si risolvono tutti i difetti aperti, quindi insieme all'esecuzione di scenari in sospeso ora è necessario ripetere il test di tutti i difetti che sono atterrati in un bucket di prova. Continuando comunque con buoni progressi alla fine il numero di scenari completati diventa 200 con ulteriori difetti.

Ora puoi segnalare solo i difetti di Gravità 2 e Gravità 3.

Inserendo queste informazioni in forma tabulare:

Dovresti fermarti qui?

Hai ha coperto completamente tutti gli scenari di test una volta e hanno aperto alcuni difetti importanti. Fermarsi a questo punto ti darà fiducia sul software?

Non proprio per i seguenti motivi:

• Tutti gli scenari vengono eseguiti una sola volta.
• Il software presenta ancora molti difetti importanti.
• La regressione non è coperta.

Possiamo vedere che la qualità è compromessa sopra entrambi gli scenari. L'approccio migliore sarà trovare un punto in cui tutti i fattori dello scenario 1 e dello scenario 2 siano coperti e anche la qualità non sia compromessa. Per ottenere ciò dovremo definire alcuni criteri all'inizio del test.

Questi criteri sono definiti come criteri di completamento o di uscita. È la risposta alla nostra domanda: 'Quando interrompere il test?'.

Che cosa sono i criteri di completamento o di uscita?

I criteri di uscita vengono valutati alla fine del ciclo di test e sono definiti nel Piano di test. È l'insieme di condizioni o attività che devono essere soddisfatte per concludere i test.

I criteri di uscita definiscono quanto test è sufficiente e quando le attività di test possono essere dichiarate complete. Copertura e i criteri di completamento vengono combinati per definire i criteri di uscita per il test.

Cosa dovrebbe essere presente nei criteri di uscita?

Idealmente, i criteri di uscita o di arresto sono definiti combinando vari fattori e quindi sono unici in tutti i progetti. Dipende dai requisiti del progetto e quindi dovrebbe essere definito durante la pianificazione del test; all'inizio del progetto. I parametri definiti in esso dovrebbero essere quantificati il ​​più possibile.

Di seguito sono riportati alcuni suggerimenti da considerare durante la definizione dei criteri di uscita in caso di test funzionale o di sistema. È possibile combinare alcuni o tutti i seguenti fattori mentre si decide dove interrompere il test in base alle esigenze del progetto.

Il test può essere interrotto quando:

Requisiti:

• Viene raggiunta la copertura dei requisiti al 100%.

Difetti:

• È stato raggiunto il conteggio dei difetti definiti / desiderati.
• Tutti i difetti o i blocchi di Show Stopper sono corretti e nessun difetto critico / di gravità 1 noto è in stato Aperto.
• Tutti i difetti ad alta priorità vengono identificati e corretti.
• Il tasso di difetti è inferiore al tasso accettabile definito.
• Pochissimi difetti di priorità media sono aperti e hanno una soluzione alternativa.
• Pochissimi difetti aperti a bassa priorità che non influiscono sull'utilizzo del software.
• Tutti i difetti ad alta priorità vengono nuovamente testati e chiusi e gli scenari di regressione corrispondenti vengono eseguiti con successo.

Copertura del test:

• La copertura del test dovrebbe essere raggiunta al 95%.
• Il tasso di superamento del test dovrebbe essere del 95%. Questo può essere calcolato dalla formula
  • (Numero totale di TC superato / Numero totale di TC) * 100.
• Tutti i casi di test critici vengono superati.
• 5% I casi di test possono essere falliti ma i casi di test non riusciti hanno una priorità bassa.
• Si ottiene una copertura funzionale completa.
• Tutti i principali flussi funzionali / aziendali vengono eseguiti correttamente con vari input e funzionano correttamente.

Scadenze:

• La scadenza del progetto o la scadenza del termine del test è stata raggiunta.

Documenti di prova:

• Tutti i documenti / risultati del test (Esempio - Rapporto di riepilogo del test ) vengono preparati, revisionati e pubblicati su.

Budget:

• Il budget completo del test è esaurito.

Riunioni 'Go / No Go':

• ' Go / No Go ' incontro è stato condotto con le parti interessate e si decide se il progetto debba o meno andare in produzione.

Conclusione:

Rendiamolo molto semplice alla fine.

Rispondi alle domande con un semplice Sì o No.

Se ottieni la maggior parte delle risposte come Sì, significa che puoi interrompere il test a questo punto. Se la maggior parte delle risposte è No, significa che devi controllare cosa manca al test e questo potrebbe aiutarti a trovare un difetto di produzione in fuga :)

• Tutti i casi di test vengono eseguiti almeno una volta?
• Il tasso di superamento dello scenario di test è definito?
• È stata raggiunta la copertura completa del test?
• Tutti i flussi funzionali / aziendali vengono eseguiti almeno una volta?
• È stato raggiunto il conteggio dei difetti stabilito?
• Tutti i principali difetti ad alta priorità sono stati risolti e chiusi?
• Tutti i difetti sono stati riesaminati e chiusi?
• È stata eseguita la regressione per tutti i difetti aperti?
• Hai esaurito il budget per i test?
• È stata raggiunta l'ora di fine del test?
• Tutti i risultati dei test vengono esaminati e pubblicati?

Circa l'autore: Questo è un articolo di Renuka K. Ha più di 11 anni di esperienza nel test del software.

Spero che questo articolo ti sia stato utile. Vorrei anche sentire i vostri pensieri / commenti sull'argomento.

Buon test!

Lettura consigliata

• Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
• Lavoro assistente QA test software
• Programma del corso di test del software - Piano di formazione dettagliato del corso online
• Corso di test del software: quale istituto di test del software dovrei iscrivermi?
• Scegliere il test del software come carriera
• Lavoro di freelance di scrittore di contenuti tecnici di test del software
• Alcune interessanti domande di intervista sul test del software
• Feedback e recensioni sul corso di test del software