Problemi di classificazione della gravità dei bug

Hai un libro che formula suggerimenti come classificare i problemi, e i suggerimenti tralasciano alcuni casi intermedi - perché il tuo libro cerca semplicemente di darti una linea guida approssimativa su come potrebbe em> essere classificato, non meno, non di più. Proprio come ogni libro, tali regole non dovrebbero impedirti di pensare da solo.

Pensa a questo nel contesto di il tuo caso specifico del mondo reale (ad esempio, quando implementa un tracker di problemi in un'organizzazione, per un sistema software specifico): come tu vogliono che le questioni siano categorizzate? Dove traccia la linea tra caratteristiche "critiche" e "fondamentali" nel tuo contesto (c'è anche una differenza)? Sono quelle di cui hai bisogno in 4 categorie, ne hai bisogno di più, ne hai bisogno di meno? Forse il tuo tracker di problemi consente di inserire attributi sia per "l'importanza della funzionalità interessata" sia per "esiste una soluzione alternativa?"

C'è una buona metafora, la scala di gravità del problema è relativa .
Il nostro unico obiettivo è fornire mezzi per dare la priorità agli sforzi di risoluzione dei bug. L'ultima domanda è: "su quali argomenti concentrarsi, in primo luogo?", E la risposta è un elenco ordinato di problemi. Se l'elenco non funziona in questo modo, diventa inutile.

Ci sono molte considerazioni specifiche per il prodotto su cui stai lavorando:

• Soluzioni alternative potrebbero essere o non essere affatto pertinenti.
  Supponiamo che tu stia sviluppando un firmware per una lavatrice e che un determinato pulsante non funzioni come previsto: potresti considerare anche se è una soluzione alternativa premendo simultaneamente altri due pulsanti?
• Anche la definizione di "Caratteristica critica" cambia.
  Supponiamo che tu stia lavorando sulla versione 15 del tuo prodotto e che abbia pianificato la funzione di A .
  Secondo i tuoi piani, ci sarà un'altra funzionalità B pianificata per la versione # 16.
  È stato riscontrato un errore nella funzione B e è necessario assegnare la gravità. Indipendentemente dal fatto che B sarà diventare critico per la versione 16, è non così importante per la versione corrente. Quindi gli assegni un livello medio di gravità in modo che gli sviluppatori non stiano perdendo il loro tempo adesso. Non appena viene rilasciata la versione 15, la gravità deve essere aggiornata.

È impossibile tracciare linee chiare tra queste categorie. In pratica, non importa. Assegniamo categorie per comunicare con le persone che risponderanno ai difetti. Quando viene rilevato un difetto, scegliere la categoria che susciterà la risposta più utile per l'azienda. Se deve essere risolto il prima possibile, e preferibilmente prima, è decisamente critico. Se è importante, ma può essere gestito durante il normale orario di lavoro, forse è alto.

Le organizzazioni non dovrebbero creare processi in cui l'esatta categorizzazione dei difetti porta benefici finanziari. Ciò crea incentivi per lavorare al di fuori del sistema di tracciamento dei difetti.