Quando è possibile spedire un prodotto con un bug noto?

20

Quando va bene spedire un prodotto con un bug noto?

    
posta Pritam Karmakar 11.03.2011 - 09:10
fonte

14 risposte

12

Suppongo tu stia parlando di un bug "noto" (la domanda non ha significato altrimenti). Bene, la risposta dipende da questi fattori:

1) Chi è l'utente e come accetterà il bug nel caso in cui venga trovato?

2) Qual è il potenziale impatto (danno) del bug?

3) È possibile ritardare la spedizione del software per correggere il bug?

4) La cosa più importante: cosa ti aspetti dal tuo software? Time-to-market? Qualità? Vuoi vedere se i tuoi clienti usano il software abbastanza a lungo da trovare il bug?

    
risposta data 11.03.2011 - 12:32
fonte
120

Deve sempre essere OK, perché non esiste software bugless.

    
risposta data 11.03.2011 - 09:12
fonte
33

È un giudizio. Ricorda, un bug può essere molte cose. Se si tratta di una funzionalità importante che non funziona, allora la aggiusti prima. Se è qualcosa di minore che ha un impatto reale minimo o nullo sugli utili del programma, potresti lasciarlo scivolare.

Quindi guardalo da un punto di vista costi / benefici.

Spedisci prodotti con bug noti quando il costo totale e il rischio di correggere il bug superano qualsiasi problema e l'impatto negativo potrebbe derivare dal bug in circolazione.

Quindi, se hai un periodo di test di 2 settimane prima del rilascio, e viene trovato un piccolo bug, la domanda è ... sta correggendo quel bug che valeva le 2 settimane aggiuntive che un team potrebbe ora spendere per ri-testare il applicazione e installazione (un passaggio spesso dimenticato nella creazione di software)? Quali sono i costi per la reputazione o le vendite se il software è in ritardo? Le persone si arrabbieranno? Potrebbero essere abbastanza felici di vivere con un bug minore se la funzionalità principale può essere fornita in tempo.

I rischi includono il rischio di introdurre un nuovo problema, non solo nel correggere il bug, ma anche le cose che potrebbero sorgere dalla creazione di una nuova installazione.

L'impatto negativo è sia il tempo che gli sforzi per gestire i clienti che segnalano il bug e cose come il danno alla reputazione.

    
risposta data 11.03.2011 - 09:32
fonte
6

I bug hanno diverse gravità. In qualsiasi azienda di software in cui ho lavorato, abbiamo classificato i bug in ordine di priorità da P0 a P4.

P0 Il software non funziona / va in crash e potrebbe causare danni al business dei clienti. P1 Non funziona come progettato e si blocca in modo coerente nelle funzionalità di base P2 Si blocca di tanto in tanto e alcune funzionalità secondarie potrebbero non funzionare. P3 Alcuni elementi del software non funzionano come previsto / previsto P4 Problema cosmetico.

Ho lavorato in luoghi in cui i P4 non vengono corretti perché hanno un così piccolo effetto sul software.

Direi che va bene spedire se il tuo software ha conosciuto problemi di P3 / P4, metterei questo nelle note di rilascio e tieni presente che sono stati elaborati.

Non avrei mai rilasciato software con un problema P0, P1 o P2 di cui ero a conoscenza.

    
risposta data 11.03.2011 - 13:00
fonte
5

Si chiama " Problema noto ". Google, Microsoft, Apple, ecc. Spediscono tutti prodotti con bug, sia noti che sconosciuti. Cerca di ridurli al minimo, ma non aspettare la perfezione. Spedisci velocemente, spedisci spesso.

    
risposta data 11.03.2011 - 18:17
fonte
3

Non puoi spedire software senza bug. Il consiglio che posso dare è che è sempre meglio dire al tuo cliente: "Questa versione non può fare questo e quello, ma stiamo andando a risolvere questo" rispetto alla situazione in cui il cliente ti dice che hai un bug.

    
risposta data 11.03.2011 - 09:21
fonte
0

quando è una "caratteristica"! ;)

Su una nota seria, a meno che tu non sia un programmatore perfetto con una perfetta configurazione di test, per testare perfettamente ogni singolo percorso di codice e alla fine che potrebbe potenzialmente esistere, è improbabile che spedirai un prodotto privo di bug.

Pertanto, sii pragmatico, se tutto ciò che hai riscontrato nei tuoi test è stato corretto, qualsiasi cosa extra dovrebbe essere risolta in base alle necessità.

    
risposta data 11.03.2011 - 12:05
fonte
0

Se sei onesto con i tuoi clienti, puoi spedire con bug. Raccontare loro di tutti i bug esistenti mostra loro che hai una buona conoscenza del tuo software, e che è davvero ben collaudato (se lo è ..). :)

Ovviamente la cosa migliore è evitare le spedizioni con errori.

    
risposta data 11.03.2011 - 16:24
fonte
0

Spesso è meglio avere una spedizione del prodotto in tempo, con un elenco di problemi noti, che non spedire affatto.

Una delle cose nel mondo della programmazione che dà sicurezza alle persone in un progetto è se hanno rilasciato pianificato e se la pianificazione contiene .

Questo è il motivo per cui Ubuntu viene rilasciata ogni semestre, anche se ci sono ancora problemi aperti.

    
risposta data 11.03.2011 - 16:26
fonte
0

Direi che una buona regola empirica è, "questo bug è uno showstopper?"

Se il bug causa il fallimento di uno "scenario percorso felice", allora assolutamente non viene spedito con quel bug.

Se il bug causa il fallimento di uno "scenario tangente verso il percorso felice" e non c'è una soluzione alternativa, non spedire con quel bug.

Se un bug è documentato e c'è una soluzione nota, allora è probabilmente OK spedire con quel bug.

    
risposta data 11.03.2011 - 17:35
fonte
0

Dal punto di vista dei consumatori ... Mai. Il mio punto è che finché sai che c'è un grosso problema nel software, non dovresti mai spedirlo. Tuttavia, le forze della natura (business) prevalgono su questo se il ciclo di produzione del software è ora nella fase in cui può danneggiare il modello di business e sono bug minori che non saranno: (i) compromettere la sicurezza del software (ii) impatto sull'usabilità

    
risposta data 11.03.2011 - 17:55
fonte
0

Come hanno detto le persone, è una domanda molto ampia. In realtà mi porta a una prospettiva interessante: i cosiddetti "bug" che si sostiene sono solo i difetti che sono stati scoperti dai tester. Ci potrebbero essere infinite altre scappatoie. Ho appena ricordato una storia interessante che ho ascoltato da un rispettato professore in un seminario di laurea: quando le persone in uno dei paesi scandinavi utilizzavano una macchina per il voto di tipo "riconoscibile per la scrittura a mano", alcune persone hackeravano l'intero sistema scrivendo codice SQL malevolo (che il sistema ha preso come input normale).

    
risposta data 11.03.2011 - 19:15
fonte
0

C'è qualcosa chiamato FMEA (modalità di errore ed analisi degli effetti) è molto utile per decidere quando un bug noto è importante o non basato su:

  1. Presenza
  2. Gravità
  3. Rilevamento
risposta data 12.03.2011 - 12:37
fonte
0

Un altro fattore decisivo può essere il modo in cui il difetto si riferisce alla tua ultima versione. Se il bug fa parte di una funzione nuova, ma rotta, la non funzionalità non rappresenta una regressione delle funzionalità. Vai avanti e spedisci.

D'altra parte, se il difetto causa una perdita di funzionalità esistente che è nota per essere utilizzata dai clienti esistenti, allora deve bloccare la versione. Tale versione sarebbe un downgrade per i tuoi clienti e non servirebbe né i tuoi interessi né i loro.

Ci possono essere sfumature di grigio in questo. Una regressione nella funzionalità di base non dovrebbe mai uscire dalla porta. Alcune regressioni nelle funzionalità periferiche potrebbero essere utilizzate per guidare gli utenti se il rilascio contiene anche nuove funzionalità a cui hanno espresso interesse. Un oscuro difetto che probabilmente non influirà su molti clienti può essere rilasciato, a condizione che venga fornita una soluzione quando incide su quei clienti. I difetti nelle funzionalità altamente sperimentali che sono disattivati di default comunque non dovrebbero mai causare il ritardo della pubblicazione.

    
risposta data 13.03.2011 - 08:40
fonte

Leggi altre domande sui tag