Processo di gestione dei difetti nei test del software

Cos'รจ il processo di gestione dei difetti?

La gestione dei difetti รจ un processo sistematico per identificare e correggere i bug. Un ciclo di gestione dei difetti contiene le seguenti fasi: 1) Scoperta del difetto, 2) Categorizzazione del difetto, 3) Correzione del difetto da parte degli sviluppatori, 4) Verifica da parte dei tester, 5) Chiusura del difetto, 6) Segnalazioni del difetto alla fine del progetto.

Questo argomento ti guiderร  su come applicare il processo di gestione dei difetti al sito web del progetto Guru99 Bank. รˆ possibile seguire i passaggi seguenti per gestire i difetti.

Processo di gestione dei difetti

Passaggio 1) Scoperta

Nella fase di scoperta, i team di progetto devono scoprire come molti difetti come possibile, prima che il cliente finale possa scoprirlo. Si dice che un difetto venga scoperto e cambi di stato accettato quando viene riconosciuto e accettato dagli sviluppatori

Nello scenario sopra riportato, i tester hanno scoperto 84 difetti nel sito web Guru99.

Scoperta

Diamo un'occhiata al seguente scenario; il tuo team di testing ha scoperto alcuni problemi nel sito web di Guru99 Bank. Li considera difetti e li ha segnalati al team di sviluppo, ma c'รจ un conflitto:

In tal caso, come Test Manager, cosa farai?

A) Concorda con il team di test che si tratta di un difetto

B) Il Responsabile del Test assume il ruolo di giudice per decidere se il problema รจ un difetto o meno

C) Concorda con il team di sviluppo che non รจ un difetto

Corretta
Non corretto

In tal caso, dovrebbe essere applicato un processo di risoluzione per risolvere il conflitto, assumendo il ruolo di giudice per decidere se il problema del sito web รจ un difetto o meno.

Passaggio 2) Categorizzazione

La categorizzazione dei difetti aiuta gli sviluppatori di software a dare prioritร  ai loro compiti. Ciรฒ significa che questo tipo di prioritร  aiuta gli sviluppatori a correggere prima quei difetti che sono estremamente cruciali.

categorizzazione

I difetti sono solitamente classificati dal Responsabile del test:

Facciamo un piccolo esercizio come segue

Trascina e rilascia la prioritร  del difetto qui sotto
1) Le prestazioni del sito web sono troppo lente
2) La funzione di accesso del sito web non funziona correttamente
3) La GUI del sito Web non viene visualizzata correttamente su Mobile dispositivi
4) Il sito web non รจ in grado di ricordare la sessione di accesso dell'utente
5) Alcuni collegamenti non funzionano

Ecco le risposte consigliate

No. Descrizione Prioritร  Spiegazione

1

Le prestazioni del sito web sono troppo lente

Alto

Il bug delle prestazioni puรฒ causare enormi disagi all'utente.

2

La funzione di accesso del sito web non funziona correttamente

critico

L'accesso รจ una delle funzioni principali del sito Web bancario, se questa funzione non funziona, si tratta di bug gravi

3

La GUI del sito Web non viene visualizzata correttamente sui dispositivi mobili

Medio

Il difetto colpisce l'utente che utilizza lo Smartphone per visualizzare il sito web.

4

Il sito web non รจ riuscito a ricordare la sessione di accesso dell'utente

Alto

Questo รจ un problema serio poichรฉ l'utente sarร  in grado di accedere ma non di eseguire ulteriori transazioni

5

Alcuni collegamenti non funzionano

Basso

Questa รจ una soluzione semplice per gli sviluppatori e l'utente puรฒ comunque accedere al sito senza questi collegamenti

Passaggio 3) Risoluzione dei difetti

Risoluzione dei difetti nel test del software รจ un processo passo passo per correggere i difetti. Il processo di risoluzione dei difetti inizia con l'assegnazione dei difetti agli sviluppatori, quindi gli sviluppatori pianificano la correzione del difetto in base alla prioritร , quindi i difetti vengono corretti e infine gli sviluppatori inviano un rapporto di risoluzione al responsabile del test. Questo processo aiuta a correggere e tenere traccia facilmente dei difetti.

Per correggere il difetto รจ possibile seguire i passaggi seguenti.

Risoluzione dei difetti

  • Assegnazione: assegnato a uno sviluppatore o altro tecnico per la correzione e ha modificato lo stato in Rispondendo.
  • Fissazione del programma: Il lato sviluppatore si fa carico di questa fase. Creeranno un programma per correggere questi difetti, a seconda della prioritร  del difetto.
  • Correggi il difetto: Mentre il team di sviluppo corregge i difetti, il Responsabile del test tiene traccia del processo di correzione dei difetti rispetto al programma sopra riportato.
  • Segnala la delibera: ottieni un report sulla risoluzione dagli sviluppatori quando i difetti vengono risolti.

Passaggio 4) Verifica

Dopo il team di sviluppo fisso e segnalati il difetto, il team di test verifica che i difetti siano effettivamente risolti.

Ad esempio, nello scenario precedente, quando il team di sviluppo segnala di aver giร  corretto 61 difetti, il tuo team eseguirร  nuovamente il test per verificare che questi difetti siano stati effettivamente risolti o meno.

Passaggio 5) Chiusura

Una volta che un difetto รจ stato risolto e verificato, lo stato del difetto viene modificato in chiuso. In caso contrario, รจ necessario inviare un avviso allo sviluppo per verificare nuovamente il difetto.

Passaggio 6) Segnalazione dei difetti

Segnalazione dei difetti nel test del software รจ un processo in cui i responsabili dei test preparano e inviano il rapporto sui difetti al team di gestione per un feedback sul processo di gestione dei difetti e sullo stato dei difetti. Quindi il team di gestione controlla la segnalazione dei difetti e invia feedback o fornisce ulteriore supporto, se necessario. La segnalazione dei difetti aiuta a comunicare, monitorare e spiegare meglio i difetti in dettaglio.

Il consiglio di amministrazione ha il diritto di conoscere lo stato del difetto. Devono comprendere il processo di gestione dei difetti per supportarti in questo progetto. Pertanto, รจ necessario segnalare loro l'attuale situazione dei difetti per ottenere un feedback da loro.

Perchรฉ hai bisogno del processo di gestione dei difetti?

Il tuo team ha riscontrato bug durante il test del progetto Guru99 Banking.

Processo di gestione dei difetti

Dopo una settimana lo sviluppatore risponde:

Processo di gestione dei difetti

Nella prossima settimana il tester risponde

Processo di gestione dei difetti

Come nel caso precedente, se la comunicazione del difetto avviene verbalmente, presto le cose diventano molto complicate. Per controllare e gestire efficacemente i bug รจ necessario un ciclo di vita dei difetti.

Metriche importanti dei difetti

Sostenere lo scenario di cui sopra. Lo sviluppatore e i team di test hanno esaminato i difetti segnalati. Ecco il risultato di quella discussione

Metriche importanti dei difetti

Come misurare e valutare la qualitร  dell'esecuzione del test?

Questa รจ una domanda che ogni Responsabile del test vuole sapere. Ci sono 2 parametri che puoi considerare come segue

Metriche importanti dei difetti

Nello scenario sopra, puoi calcolare il rapporto di rifiuto della defezione (DRR) รจ 20/84 = 0.238 (23.8%).

Un altro esempio, supponiamo che il sito web della Guru99 Bank abbia total 64 difetti, ma il tuo team di test rileva solo 44 difetti cioรจ mancavano 20 difetti. Pertanto, รจ possibile calcolare che il rapporto di perdita del difetto (DLR) รจ 20/64 = 0.312 (31.2%).

Conclusione, la qualitร  dell'esecuzione del test viene valutata tramite i seguenti due parametri

Metriche importanti dei difetti

Minore รจ il valore di DRR e DLR, migliore รจ la qualitร  dell'esecuzione del test. Qual รจ l'intervallo di rapporti corrispondente? accettabile? Questo intervallo potrebbe essere definito e accettato come base nell'obiettivo del progetto oppure รจ possibile fare riferimento alle metriche di progetti simili.

In questo progetto, il valore consigliato del rapporto accettabile รจ 5~10%. Significa che la qualitร  dell'esecuzione del test รจ bassa. Dovresti trovare contromisure per ridurre questi rapporti come

  • Migliorare le capacitร  di test del membro.
  • Trascorrere piรน tempo per l'esecuzione dei test, in particolare per la revisione dei risultati dell'esecuzione dei test.

Domande Frequenti

Un bug รจ la conseguenza/esito di un errore di codifica.

A Difetto nel test del software รจ una variazione o deviazione dell'applicazione software dai requisiti dell'utente finale o dai requisiti aziendali originali. Un difetto del software รจ un errore nella codifica che provoca risultati errati o imprevisti da un programma software che non soddisfa i requisiti effettivi. I tester potrebbero riscontrare tali difetti durante l'esecuzione dei casi di test.

Questi due termini hanno una differenza molto sottile. Nell'industria entrambi sono difetti che devono essere risolti e quindi utilizzati in modo intercambiabile da alcuni dei Collaudo squadre.

Quando i tester eseguono i casi di test, potrebbero imbattersi in risultati di test contraddittori rispetto ai risultati attesi. Questa variazione nei risultati del test viene definita difetto del software. Questi difetti o variazioni vengono indicati con nomi diversi in diverse organizzazioni come questioni, problemi, bug o incidenti.

Una segnalazione di bug nel test del software รจ un documento dettagliato sui bug rilevati nell'applicazione software. La segnalazione di bug contiene tutti i dettagli sui bug come descrizione, data in cui รจ stato trovato il bug, nome del tester che lo ha trovato, nome dello sviluppatore che lo ha risolto, ecc. La segnalazione di bug aiuta a identificare bug simili in futuro in modo che possano essere evitati.

  • ID_difetto โ€“ Numero identificativo univoco del difetto.
  • Difetto Descriptione โ€“ Descrizione dettagliata del Difetto comprese le informazioni sul modulo in cui รจ stato riscontrato il Difetto.
  • Versione โ€“ Versione dell'applicazione in cui รจ stato riscontrato il difetto.
  • Passaggi - Passaggi dettagliati insieme a screenshot con cui lo sviluppatore puรฒ riprodurre i difetti.
  • Data di nascita โ€“ Data in cui viene segnalato il difetto
  • Riferimento- dove in Fornisci riferimento ai documenti come requisiti, progettazione, architettura o forse anche screenshot dell'errore per aiutare a comprendere il difetto
  • Rilevato da โ€“ Nome/ID del tester che ha segnalato il difetto
  • Stato - Stato del difetto, ne parleremo piรน avanti
  • Risolto da โ€“ Nome/ID dello sviluppatore che ha risolto il problema
  • Data di chiusura โ€“ Data in cui il difetto รจ stato chiuso
  • Gravitร  che descrive l'impatto del difetto sull'applicazione
  • Prioritร  che รจ correlato all'urgenza della correzione dei difetti. La prioritร  di gravitร  potrebbe essere Alta/Media/Bassa in base all'urgenza dell'impatto con cui il difetto dovrebbe essere corretto rispettivamente

Clicchi Qui. se il video non รจ accessibile

Risorse:

Scarica un modello di segnalazione dei difetti di esempio

Riassumi questo post con: