Il feedback degli errori non fornisce un bug critico? [duplicare]

Mi piace avere una politica di zero-difetti , che rende è molto più facile classificare i difetti.

Chi dovrebbe fare questa classificazione? Vorrei lasciare la classificazione a un imprenditore. Se fossi un imprenditore qui farei un miglioramento, sembra che manchi la gestione degli errori.

Ancora se questo fosse durante lo sviluppo di una nuova funzionalità, quindi qualcosa non ancora rilasciato. Vorrei spingere il QA e lo sviluppo per testare e migliorare questo aspetto prima che venga spedito. Ma anche in questo caso le priorità potrebbero essere diverse, quindi assicurati di discuterne con qualcuno che stabilisce le priorità . Molto spesso questo non è un QA né uno sviluppatore.

Ricorda che se tutto ha una priorità alta, niente lo è. Non ha senso usare solo blocker, critical e major, ignorando le priorità più basse.

Dovresti creare una politica che definisca cosa significano queste etichette e quali sono le conseguenze.

Ad esempio li usiamo più o meno così:

Blocker

I tempi di inattività, le funzionalità essenziali non funzionano, i pagamenti non corretti, le vulnerabilità della sicurezza pubblica ...

Nella produzione: ogni minuto conta. Lavora per pranzo / fuori orario di lavoro. Salta le riunioni. Riduci i test per accelerare la distribuzione.

Prima della versione: la distribuzione di questo è fuori questione.

Critical

Rottura significativa ma contenuta. Corruzione dei dati correggibile che interessa solo una piccola minoranza di utenti.

In produzione: prova a risolverlo oggi, ma anche domani è accettabile. Ha la precedenza sulla prioritizzazione ordinaria dei compiti. Salta incontri più lunghi / meno importanti. Provalo ancora correttamente prima della distribuzione. Giustifica una correzione / distribuzione autonoma.

Prima della versione: ritardare le pubblicazioni annunciate, se necessario, fallire le scadenze impegnate dai clienti.

Maggiore

Le funzioni meno importanti non funzionano. Nessuna corruzione dei dati o impatto a lungo termine. Fastidi al cliente con soluzioni alternative accettabili. Un cliente interessato non sarà felice, ma potrà vivere con la limitazione / soluzione temporanea a breve termine.

In produzione: risolvilo entro una settimana circa. Più importante della maggior parte delle nuove funzionalità, ma come sempre. Arrotalo nella prossima distribuzione dopo il completamento.

Prima della versione: ritarda le versioni discrezionali, ma non le versioni annunciate / impegnate.

Normal

Al livello di parità delle tipiche nuove funzionalità.

Minore

Errori di ortografia, piccoli errori grafici

Probabilmente classificherei il tuo problema come maggiore su questa scala, o forse solo normale se si tratta di una caratteristica usata raramente (specialmente se non è rivolta al cliente).

Esiste un difetto di implementazione quando c'è una differenza tra comportamento previsto e comportamento effettivo. Questo dovrebbe essere un dato di fatto, non un'opinione.

Se il comportamento effettivo non è definito, non è un difetto, è un requisito gap . Dovrebbe essere indirizzato dall'analista aziendale proprietario del set di requisiti.

Suggerirei in caso di accesso, un messaggio di errore specifico non solo non è necessario, ma potrebbe essere dannoso ed è contrario a raccomandazioni sulle best practice . Tuttavia, la sicurezza è sempre un equilibrio tra costi, rischi e convenienza, ea volte un'organizzazione sceglie di fornire almeno alcune informazioni nel messaggio di errore di accesso. Quella decisione non giace con te o con la QA, ma con gli stakeholder aziendali.

Anche se @Ben Cottrell è corretto, ti suggerisco di provare a visualizzare la gravità dagli occhi dell'utente del sistema. Come fa a gestire il feedback mancante? Cerca di rendere chiaro anche questo punto di vista agli sviluppatori: non sono programmabili per qualcuno che può vedere il codice sorgente in qualsiasi momento, stanno programmando per qualcuno che vuole lavorare con l'interfaccia del sistema.

In generale, dovresti cercare di rendere il tuo sistema il più facile da usare possibile e il più delle volte, i messaggi di errore sono una parte fondamentale di questo obiettivo. Ricorda tutte le volte in cui il sistema ha detto e non hai idea di cosa sia andato storto? Questo è il tuo sistema ora - i tuoi utenti lo adoreranno! Mi piacciono molto gli errori esplicativi che RavenDB lancia in molti punti: descrivi qual è il problema e cosa puoi fare per correggerlo. Certo, questa è una grande stringa che passi, ma è molto più utile come "errore 42"