Classificazione bug / difetti del software [chiusa]

Le classifichiamo come

• change-request (piccoli miglioramenti, cambiamento di comportamento)
• design-change-request (grandi funzionalità che richiedono un documento di progettazione)
• sw-bug (bug del software a causa di un errore del programmatore)
• test-bug (non proprio un bug del software, errore del tester nel suo script)
• richiesta di supporto (richiesta di informazioni / chiarimenti, solitamente dal campo)
• non valido (il problema segnalato non esiste o è il comportamento previsto)
• duplicato (lo stesso identico problema era già stato segnalato)
• doc-bug (errore di documentazione, la documentazione deve essere aggiornata con un comportamento corretto) (Grazie a Michael per aver indicato questo)

Nel progettare la classificazione per il nostro bugtracker, ho cercato di essere molto consapevole dello scopo di ogni campo. Ecco cosa abbiamo finito.

Quando ci lavoreremo?

Questo campo registra i risultati della nostra pianificazione. È molto utile cercare e filtrare su: quando uno sviluppatore è fuori dalle attività (tutto ciò che gli viene assegnato è fatto, o il suo lavoro è bloccato per qualsiasi motivo) può semplicemente prendere un problema dalla lista di tutti i bug non assegnati ordinati per "Quando ":

Spessospostiamoiproblemitra"Ora" e "Avanti" e rivediamo le attività "Presto" di volta in volta e dopo un rilascio. Occasionalmente eseguiamo le attività "Più tardi". "Se mai" è il campo che utilizziamo al posto delle richieste di chiusura, non siamo sicuri che avremo mai intenzione di lavorare.

Quanto ci vorrà per risolvere?

Questo campo è la nostra migliore stima di quanto tempo è probabile che il lavoro prenda. È notoriamente difficile avere un'idea di questo, ma a causa della scala logaritmica e della ruvidezza dell'ordine di grandezza raramente siamo fuori da più di una voce in questo elenco:

Questocampoèusatoindiversecircostanze.Innanzitutto,èunaconsiderazioneimportanteperquantoriguardailcampo"Quando" discusso sopra. Mi piace usare questo campo per scegliere un compito molto breve con cui iniziare il lunedì se non mi sento troppo motivato. È anche utile trovare lavoro per un nuovo dipendente o qualcun altro che non si sente motivato.

Quanto è importante questo compito, nel grande schema delle cose?

Questo campo è per chi pianifica il progetto; gli sviluppatori non si preoccupano davvero. Aiuta a registrare quanto pensiamo che questo lavoro sia importante per il successo del nostro progetto:

Vieneutilizzatoinsiemea"Quanto ci vorrà" per decidere quando lavoreremo a questa attività.

Qual è lo stato del bug?

Questo campo è usato per il flusso di lavoro. Ogni stato mostrato di seguito è uno stato "aperto" o "chiuso". Il bugtracker ha scorciatoie per mostrare solo bug aperti, e questo è l'uso principale per questo campo.

Lasuddivisioneinaperto/chiusoèloscopoprincipalediquestocampo,tuttaviaognisingolavoce"chiusa" agisce per riassumere il risultato. Questo può essere spesso dedotto anche dai commenti, ma aiuta ad avere un luogo standard in cui è possibile trovare queste informazioni.

C'è una regola imposta da bugtracker che un bug Duplicato deve avere almeno un link per dire di che duplicato sia il bug.

Siamo piuttosto espliciti riguardo al non utilizzare uno stato "in corso" perché, a seguito di esperienze passate, è molto difficile tenerlo aggiornato correttamente e, di conseguenza, lo stato può fare più male che bene.

Di cosa si tratta?

Questo è il campo più vicino al convenzionale "tipo di bug". Il suo scopo principale è descrivere la voce a un umano . Quasi mai non cerchiamo o filtriamo su questo campo. È solo lì per salvare le parole nel titolo del bug. L'elenco varia in qualche modo da progetto a progetto, ma ecco un esempio rappresentativo:

Campivuoti

Scegliereunvalorepertuttoquantosopranonèsemprefacile,quindipermettiamoallapersonacheentranelbugdilasciarevuotiicampichenonriesconoacapireinquestomomento.Manteniamol'atteggiamentosecondoilqualetuttovabene,anchesetisentisolopigro,perchéaltrimentipotremmofinireconlaspazzaturainquesti.

Icampi"Quando" e "Importanza" sono spesso lasciati vuoti perché queste cose sono da decidere per il progettista del progetto. Le voci con spazio vuoto "Molto lavoro" vengono riesaminate di volta in volta, con potenziali assegnatari chiamati a stimarla.

Project-specifica

Mentre i progetti di grandi dimensioni utilizzano tutto quanto sopra, alcuni piccoli progetti ne eliminano di meno. Se non hanno alcuna utilità per "Importanza", insistiamo affinché il campo venga eliminato da quel progetto. L'idea è che siano presenti solo i campi che vengono utilizzati attivamente.

P.S. Gli screenshot di cui sopra sono di YouTrack, che mi piace molto. Non ha avuto alcun problema con noi di eliminare tutti i campi predefiniti e utilizzare il nostro.

La sezione "Test degli sviluppatori" di Code Complete classifica i difetti come:

• strutturale
• Dati
• Funzionalità come implementata
• Edilizia
• Integrazione
• Requisiti funzionali
• Test di definizione o esecuzione
• Sistema, architettura software
• specificato

(questo è originario di uno studio Beizer del 1990)

Naturalmente, la classe del difetto potrebbe essere evidente solo con il senno di poi essere riparata!

Questo schema di classificazione mantiene il tipo di difetto distinto dalla sua gravità (grave - > insignificante) e priorità (ne ho bisogno ieri - > pipe dream).

Inoltre, questo presuppone che il ticket sia già stato classificato come DEFECT , piuttosto che come ENHANCEMENT o TASK (che sono tipi di ticket molto standard).

Potrebbe essere utile qualcosa come classificazione di difetti ortogonali . L'idea è di avere una serie di opzioni in modo tale che ognuna abbia un solo valore possibile che abbia senso per ogni sottomissione. IBM Research ha alcune pagine web dedicate al concetto .

Per quanto riguarda i tipi di difetti, l'unica cosa che voglio veramente sapere è se si tratta di un difetto o se si tratta di un miglioramento. Esiste un difetto in un prodotto di lavoro che non è conforme all'artefatto che lo ha generato. Ad esempio, un requisito che non cattura adeguatamente l'intenzione dello stakeholder è difettoso. Allo stesso modo, un progetto che non soddisfa un requisito o un'implementazione che non realizza un progetto o un requisito è difettoso. Una richiesta di miglioramento o modifica potrebbe essere una modifica di un artefatto che soddisfi comunque i requisiti specificati. Questo potrebbe essere un nuovo requisito o un refactoring per ridurre il debito tecnico, come esempi.

Credo che qualsiasi schema di classificazione completo possa rispondere alle seguenti domande. Ciò che è effettivamente necessario acquisire varia in base a come si utilizzano i dati, utilizzando i dati dei difetti per tenere traccia delle attività che devono essere meno complete dei dati sui difetti che sono un input in un programma di metrica rigoroso.

• Si tratta di un problema in un prodotto di lavoro esistente o un miglioramento di un prodotto di lavoro? Qualunque cosa, sia esso un requisito, un documento o un modulo di codice, non è conforme alle specifiche o alle specifiche che i prodotti di lavoro sono basati deve essere migliorato.
• Quale prodotto del lavoro è interessato? Questo influenza un documento (e quale)? È contro il codice? Test unitari? A seconda del processo di rilascio, potrebbe anche indicare quali versioni sono interessate da questo difetto o miglioramento come elemento dati aggiuntivo.
• Qual è la priorità e / o la gravità di questo difetto? La priorità è generalmente un elemento cliente o definito dall'utente che indirizza la rapidità con cui hanno bisogno di una soluzione di qualche tipo. I difetti di priorità più alta devono essere affrontati per primi. Si noti che "indirizzato" potrebbe semplicemente significare analizzare e sviluppare un work-around fino a quando un difetto può essere adeguatamente risolto. La severità in genere definisce il modo in cui il lavoro ha un impatto: bassa severità significa che ha un impatto minimo sul valore aziendale, mentre una maggiore severità significa che gli utenti stanno riscontrando estrema difficoltà nel realizzare i propri obiettivi di business a causa del difetto.
• Quando è stato segnalato il difetto? Quando è stato finalmente risolto? Questo può essere usato per tracciare i dati time-to-closure, che potrebbero essere correlati alle metriche di soddisfazione del cliente.
• Dove è stato trovato il difetto e dove è stato originariamente iniettato? Questo è veramente necessario solo se stai acquisendo metriche di contenimento dei difetti, come il contenimento totale dei difetti (il numero di difetti trovati / riparati in casa o post -release) o l'efficacia del contenimento delle fasi. Preferisco un concetto basato sull'attività (qualcosa sulla falsariga di requisiti, architettura / design, implementazione, test, campo), trascurando le iterazioni, in modo da poter determinare quali attività sono associate a processi che sono abili nel catturare i difetti e dove ho bisogno per migliorare i miei processi.
• Che cosa ha causato l'esistenza o l'iniezione di questo difetto? Il modo in cui lo definisci dipende dalla tua organizzazione, ma PSP fornisce un buon punto di partenza . Non vuoi qualcosa di troppo complicato in modo che non possa essere compreso e, in linea con la Classificazione dei difetti ortogonali, non vuoi che i difetti possano essere messi in più categorie.
• Come posso identificare e fare riferimento a questo difetto? In genere, un identificatore univoco e un titolo breve, leggibile dall'uomo forniscono queste informazioni. Questi possono essere utilizzati per fornire informazioni a clienti / utenti sui work-in-progress e nelle relazioni sullo stato o sui registri di commit per aiutare a tracciare i difetti alla chiusura.

La maggior parte di questi, ad eccezione del motivo per cui esiste, si applica ugualmente a difetti e miglioramenti.

Prima di provare a reinventare la ruota (o la lingua inglese), non dovrebbe esserci l'accento sulla descrizione del bug?

'Bug' = non buono / indesiderato / errore / errore

Sì, è generico, ma non otterrai nulla dalla creazione di nuove parole per descrivere qualcosa di brutto.

Non definirei alcun miglioramento o miglioramento di un bug.

Generalmente classifico i problemi in un tracker dei problemi in questo modo:

• Bug - Un problema nel codice che porta all'output inatteso.
• Supporto - Qualcosa che deve essere fatto prima di poter esaminare altri problemi. vale a dire. un bug che il generatore CSV sta generando errori è dovuto al fatto che non esiste ancora un vero generatore CSV. Supporto: scrivi un generatore CSV.
• Funzionalità - Un miglioramento o un miglioramento che mi piacerebbe fare. Può essere grande o piccolo.
• Wish - Una vera caratteristica del tipo eye-in-the-sky che probabilmente non vedrà mai la luce del giorno - "non sarebbe bello se il software potesse leggere la tua mente e indirizzarti a ciò che stavi cercando automaticamente !? '
• Todo - Qualcosa che richiede investigazione / scoping prima che possa essere correttamente dettagliato / classificato.

La priorità è generalmente una questione completamente diversa. I bug possono essere qualsiasi cosa, da bassa priorità a immediata, stessa cosa con caratteristiche, desideri e generalmente sono sempre bassi.