Come si definisce la gravità (critica/alta/bassa ecc.) Dei bug?

Question

Supponendo che tu sia coinvolto nella valutazione dei bug nella tua organizzazione, come definisci i diversi livelli di gravità di questi bug?

In particolare, quali sono i diversi valori utilizzati per "Gravità"? Quali sono i criteri che usi per assegnare i valori ai bug?

Precisazione: sto solo parlando dei sintomi qui. Mettiamo da parte altre cose che influenzano l'assegnazione delle priorità come: quanto tempo ci vuole per correggere il bug, quali altri compiti sono nell'agenda del team, ecc.

Answer 1

se parliamo di soldi è fondamentale.

poi dipende da quante volte dipende da molte cose:

• tempo per risolvere

• come si cambia la produttività degli altri dipendenti

• contratto (se il bug rompe il contratto è fondamentale)

• se i dati errati vengono immessi/selezionati dal db potrebbe essere fondamentale

Dipende anche dalla tua attività.

Answer 2

È fondamentalmente bisogno di due cose: per questo

1. di gravità: è questo un bug critico? O non molto critico, come un errore estetico.
2. Priorità: qual è l'urgenza di una correzione?

Se si tiene conto di questi due, si otterrà un elenco di cosa risolvere prima.

Un errore di gravità bassa può avere una priorità elevata, ad esempio.

Answer 3

Ogni azienda è diversa. Abbiamo 5 diversi livelli qui

• Blocker
• Critical
• Maggiore
• Minore
• Trivial

Per la maggior parte i nostri tester di business definiscono la gravità del problema. Mentre eseguono il test e la corsa attraverso un bug, determinano in che modo questo avrà un impatto sul cliente e sul potenziale rilascio e assegnerà una priorità di conseguenza. Esaminiamo gli articoli che sono i più severi e vediamo se sono davvero così severi come il business li sta facendo per essere. Diverse volte i business testers hanno segnalato bug "Blocker", ma quando li analizziamo troviamo che non è poi così critico.

Per riassumere, i bug di Blocker sono gli errori che è necessario correggere immediatamente. Questi sono gli errori che impediscono al prodotto di funzionare se fosse rilasciato in quello stato.

I bug critici sono ancora bug, ma di solito c'è una soluzione alternativa o una soluzione rapida che può essere applicata dopo il rilascio.

I principali bug sono una soluzione e possono essere rimossi senza influire sulla funzionalità dell'applicazione.

I problemi minori e banali sono solitamente riservati per miglioramenti o "bello per chi ha".

Spero che questo aiuti a chiarire le cose.

Answer 4

Per quanto mi riguarda, ci sono principalmente tre livelli di gravità. A seconda della società i loro nomi potrebbero differire

Principalmente

1. Critical

2. Maggiore

3. Normale/Minore

Answer 5

Ho lavorato in molte aziende e in la maggior parte di loro ha avuto 4 livelli di gravità (non confondere sev comunque con priorità), considerare la gravità come il livello di impatto che un particolare bug/difetto ha nel sistema sotto test. Dovresti sempre misurare l'impatto considerando il contesto: numero di utenti, sistema mission-critical (reattori nucleari, avionica, attrezzature mediche), perdita di denaro o reputazione, ecc. E puoi anche usare una tassonomia dei difetti per aiutarti (es. se si tratta di un arresto del sistema o di una vulnerabilità di sicurezza rispetto a un problema estetico)

Di solito la maggior parte delle aziende utilizza 4 livelli, ho visto 5 ma la mia esperienza dice che sono cose più complicate, più difficili da implementare correttamente, Ti consiglierei anche 3 (puoi rimuovere il banale/basso dal momento che non vengono mai riparati!).

Ecco l'elenco:

• S1 - Critico - ad alto impatto, nessuna soluzione (ad esempio crash di sistema, caratteristica mancante)
• S2 - Alto/Major - alto impatto, ha una soluzione alternativa (ad esempio funzione non funziona in un altro browser)
• S3 - Medium - medio impatto (ad esempio i messaggi di errore non sono buone)
• S4 - basso/Trivial - a basso impatto (ad esempio cosmetici problemi, errori di battitura, allineamenti, ecc)

Spero che funzioni