Abbiamo lavorato con un carrello della spesa per DotNetNuke e abbiamo avuto infiniti problemi con le versioni degli sviluppatori del loro prodotto. Ogni versione risolve una cosa ma nuovi bug compaiono altrove.
So che i bug sono inevitabili e che non possiamo distruggerli tutti in quel momento, ma qualcuno può dirmi quale percentuale di bug dovrebbe essere eliminata prima che un prodotto possa essere accettato come release stabile?
Non penso che sia una questione di percentuale.
Ogni bug deve essere valutato autonomamente per decidere se si tratta di uno show-stopper per il particolare progetto in questione, in base al probabile costo del bug se non risolto prima del rilascio, e al probabile costo di ritardare il rilascio fino al bug può essere risolto.
(Ad esempio, Stack Overflow ha trascorso un po 'di tempo con un'icona di notifica che non veniva visualizzata correttamente in Chrome. I costi di quell'errore erano talmente bassi da poter essere lasciati felicemente per diverse settimane, poiché il team aveva problemi più grandi concentrarsi su.)
E ricorda che "bug" è solo una scorciatoia per "bug conosciuti". Puoi correggere il 100% dei bug conosciuti e non essere ancora in forma per il lancio, perché non hai testato abbastanza bene.
Non è possibile fornire un numero di percentuale che dovrebbe essere corretto: se risolvi il 90% dei bug, uno dei bug rimanenti potrebbe essere così grave da danneggiare la tua applicazione.
Invece, tutti i bug dovrebbero essere classificati per gravità. Alcuni suggerimenti per le classificazioni sarebbero:
Per definizione, tutti gli Show Stoppers DEVONO essere corretti, altrimenti l'applicazione non funzionerà. Bug critici dovrebbero essere corretti prima della spedizione.
Eventuali bug rimanenti, come i bug con priorità alta / media / bassa, dovrebbero essere considerati, idealmente dovrebbero essere tutti corretti, ma se questo non può essere raggiunto a causa di limiti di tempo o budget, allora ogni bug rimanente dovrebbe essere valutato e dovrebbe essere determinato se è ancora disponibile per la spedizione con il problema residuo.
Non è davvero una percentuale, Un buon modo per lavorare è monitorare il tasso di inserimento dei bug - A parità di tutti gli altri, quando inizia a cadere, il prodotto sta diventando stabile. Se dici qualcosa come "Spedisci quando x% è fisso", probabilmente spedirai un codice instabile
Quindi la risposta non è facile come "Alla percentuale x la chiamiamo una versione". È meglio dire "Una volta che il tasso di inserzione è y% della frequenza di inserimento (massima / tipica / media), il software diventa un candidato a rilascio" I candiates di rilascio sono testati per l'accettazione e rilasciati o meno dopo l'analisi di bug noti e sconosciuti. Puoi decidere di correggere bug più gravi nei candidati alla versione, ma non devi aggiungere funzionalità o apportare miglioramenti.
Utilizzando metodi statistici è possibile "determinare" bug sconosciuti. Con ciò intendo ottenere un valore statistico di quanti e quanto severi sono quelli che non hai trovato. Molti di noi hanno un istinto per questo numero, ma pochi (me compreso) possono fare i conti.
Per esempio, non stai contando e come me, non va bene in matematica, puoi andare su istinto e spedirlo solo quando è pronto .......
Se conosci un metodo per misurare la percentuale di bug rimanenti in un software, sarai l'uomo più ricco di tutti i tempi.
Se scegli come target solo i bug noti, una versione stabile non dovrebbe contenere nessuno.
Quando il software si avvicina alla spedizione, spesso ricevi molte più segnalazioni di bug e segnalazioni di bug che ti chiedono nuove funzionalità. Questo dimostra che non ci sono molti "show stoppers" che impediscono ai tuoi tester di utilizzare l'app.
Quindi parlare di "percentuale di bug risolti" non è utile ...
La programmazione non è ancora una scienza, più una miscela di scienza e creatività mescolata a poche altre cose. Non si può semplicemente misurare la qualità tramite un contatore in una segnalazione di bug. Per uno non c'è modo di sapere che sono stati inseriti tutti i bug nel sistema che porterebbero a un punteggio inferiore al reale, rovinando l'analisi.
Guardo sempre i miei bug in base a come il programma verrà utilizzato e influenzerà l'utente. Se è un cattivo sistema per gli sviluppatori che sanno quello che stanno facendo e possono evitare il bug con un po 'di digitazione in più, puoi metterlo in pratica come RC ma non è davvero una stable se deve essere usato per gli utenti che devi pensare di ogni utente come i tuoi nonni non sapranno mai cosa fare.
Mantieni i bug conosciuti il più vicino allo 0% come possibile per la quantità di tempo. Se devi mettere in pratica qualcosa con i bug, assicurati di pubblicare i bug noti in modo che le persone possano esserne a conoscenza. E cerca di assicurarti che i tuoi bug siano meno critici. Stavo creando un sistema di commenti a più livelli. Ho avuto un bug che si poteva commentare su qualsiasi post, ma il primo. beh, è stato bello ma doveva essere risolto perché qualcuno vorrà commentare il primo.
Leggi altre domande sui tag bug