Definizione di un bug del software. Blizzard Entertainment insiste sul fatto che il mio "bug" non è affatto un bug. Hanno ragione? [chiuso]


18

Secondo Wikipepdia,

Un bug del software è il termine comune utilizzato per descrivere un errore, un difetto, un errore, un errore o un errore in un programma per computer o in un sistema che produce un risultato errato o imprevisto o fa sì che si comporti in modo involontario.

Recentemente ho trovato un "bug" in StarCraft 2 che produce un risultato inaspettato: http://eu.battle.net/sc2/en/forum/topic/2868627470

Il problema è che se continuo a minimizzare StarCraft 2 per molto tempo, il gioco non si disconnette o genera alcuna forma di timeout. Si disconnette comunque dopo la prima battaglia e talvolta perde anche i dati di gioco (statistiche delle partite).

Sfortunatamente, secondo Blizzard:

Il gioco non è progettato per essere ridotto al minimo per un periodo di tempo così lungo. (Blizzard) non può considerare errato tale comportamento in quanto StarCraft II non è pensato per essere minimizzato per ore.

Quindi, il mio "bug" è davvero un bug?


31
Certo, è un bug, ma non lo risolveranno in quanto non considerano questa situazione supportata (cioè poiché non è stata progettata per funzionare in questo modo, se provi ad usarla in quel modo, tu sono da soli). E, naturalmente, c'è una semplice soluzione: non farlo.
Oded,

17
Per la cronaca, il rappresentante Blizzard ha gestito la situazione molto male. Avrebbero dovuto dire: "Grazie per aver segnalato questo errore. Lo inseriremo nel nostro sistema e lo ripareremo non appena i nostri sviluppatori lo riterranno una priorità". L'assunto implicito sarebbe che non diventerà mai una priorità. Secondo me, gestito molto male.
riwalk

29
@ Stargazer712 Blizzard ha gestito esattamente questo. Non dovrebbero stabilire l'aspettativa che risolveranno un bug che non hanno intenzione di risolvere.
MattBelanger,

3
Per essere onesti con TeleShoTTgun, penso che Blizzard avrebbe dovuto almeno definire ciò che conta come "un lungo periodo di tempo". Potrei minimizzare il gioco per andare in bagno per un paio di minuti. Non penso che sia molto tempo, ma Blizzard? Considererei> 30 minuti un "lungo periodo di tempo" in questo contesto, ma non so se Blizzard sarebbe d'accordo.
FrustratedWithFormsDesigner,

3
Old Vaudeville act - "Dottore, dottore, mi fa male quando faccio questo" - "Non farlo!"
Ciclope,

Risposte:


58

Per un team di software, un bug è un problema software che deve essere risolto. Non tutti i problemi software devono essere risolti.

L'aggiornamento del software è costoso. Blizzard ti sta dicendo che il tuo problema è un caso limite. In altre parole, il problema del caso limite che hai scoperto non è necessariamente qualcosa per cui sono stati testati o per i quali è importante tener conto. Risolvere il problema ti aiuterà, ma con ogni probabilità non aiuterà molti altri. Tuttavia, il costo per correggere l'errore potrebbe essere elevato. Al contrario, possono investire le loro risorse in nuove funzionalità o persino finire Diablo III.


3
Penso che tu abbia catturato la definizione reale, usata nella pratica. Stavo per rispondere che un bug è un comportamento diverso dalle specifiche di altri poster. Ma la realtà è che se un comportamento difettoso rientrava nella definizione delle specifiche ma avesse un impatto significativo sul business, una società lo avrebbe risolto. E come hai detto, anche se le specifiche dicono che dovrebbe funzionare e non, se il ROI è basso, la società in questione non lo aggiusterà. Bella risposta.
Matt Ryan,

2
@MattRyan: E nel mondo reale (che ho visto), se le specifiche si traducono in comportamenti errati che gli utenti aziendali chiamano "bug", il team di sviluppo di solito riclassifica formalmente la soluzione come "richiesta di modifica", non come una "correzione di bug". ;)
FrustratedWithFormsDesigner,

3
In altre parole, un "bug" o "difetto" rappresenta un requisito che non è implementato correttamente. In questo caso, non è necessario lasciare il gioco minimizzato.
Ray,

22

Questo genere di cose mi ricorda il gatto nel forno a microonde , in particolare il caso della signora Smith nel 1983.

Il punto è che ti aspetti che il prodotto funzioni in questo modo. Soprattutto perché un certo numero di prodotti simili funzionano così, cioè se li minimizzi per ore e poi li apri, funzionano (anche se il contrario non è così raro come potresti pensare).

La signora Smith sapeva per esperienza che asciugare i suoi gatti nel forno non li avrebbe danneggiati (presumendo ovviamente una certa cautela). Più precisamente per esperienza che ha avuto con tutti i forni che ha provato. Quindi suppose che sarebbe stato lo stesso per il forno a microonde che le era stato dato. Questa ipotesi era sbagliata. Le microonde non sono progettate per asciugare i gatti. Né sono forni convenzionali. Capita semplicemente di non uccidere il gatto nel processo come effetto collaterale dei processi fisici che impiegano per generare calore.

Ora, come produttore di microonde, è possibile posizionare una batteria di riscaldamento e un numero di sensori nel forno a microonde. Quest'ultimo determinerebbe se il contenuto attuale è un gatto e userebbe la bobina invece delle microonde.

Allo stesso modo, che si potrebbe produrre un forno a microonde adatto per asciugare i gatti, Blizzard potrebbe creare una versione di SC2 adatta a rimanere nello stato minimizzato per lunghi periodi di tempo.

Personalmente, sarei disposto a pagare più soldi per un forno a microonde abilitato all'essiccazione dei gatti solo per il gusto di farlo (supponendo che ci sia un grande logo per l'essiccazione dei gatti davanti che posso orgogliosamente indicare). Ma non mi interessa un gioco che può rimanere ridotto al minimo per ore.

SC2 è stato progettato per soddisfare determinati requisiti. Le tue aspettative non fanno parte di quelle. Sei libero di misurare SC2 in base alle tue aspettative. Ma se Blizzard li include tutti o meno nell'ambito delle loro esigenze è in definitiva la loro scelta.

Tutto ciò di cui potresti davvero discutere è che si tratta di un errore di progettazione. Il buon senso impone che, a meno che una parte sostanziale degli utenti non sia confusa dal design o insoddisfatta, sia abbastanza buona. Sono sicuro che se un numero sufficiente di utenti dichiarasse di condividere le tue aspettative, Blizzard avrebbe ceduto e incluso nel progetto. Ciò renderebbe il tuo problema un vero bug e Blizzard lo risolverebbe.


Bella risposta, metafora orribile. Sono così felice che qualcuno non sia stato abbastanza stupido da farlo!
Ha

11

Penso che questo sia un caso di software non utilizzato come definito dalle specifiche. Dicono

Il gioco non è progettato per essere ridotto al minimo per un periodo di tempo così lungo.

Il che significa che hanno qualche definizione da qualche parte di ciò che conta come un "lungo periodo di tempo". Se minimizzi il programma per più di un "lungo periodo di tempo", va oltre le loro specifiche e oltre ciò per cui hanno testato (supponendo che lo abbiano formalmente dichiarato) e non garantiscono ciò che accadrà. Certo, sarebbe stato bello se il manuale da qualche parte dicesse "abbiamo testato questo programma solo per essere minimizzato per periodi di tempo non superiori a 10 minuti. Riduci al minimo più a lungo di questo a tuo rischio e pericolo!".

Quindi no, non penso che sia davvero un bug. Nel mio ufficio, questo sarebbe chiamato un "problema di formazione dell'utente" (che direi sia una forma di problema di comunicazione , perché in questo caso perché non è stato comunicato all'utente un periodo massimo per minimizzare il tempo) poiché l'utente è non usare correttamente il programma. Non che sia di grande aiuto per Blizzard, a meno che non lo inseriscano nel manuale ...


3
Per un sistema mission-critical, abbiamo un requisito che dice "questo sistema deve rimanere operativo per n ore" e testiamo e documentiamo esternamente che il sistema funziona per n ore. Potremmo anche documentare internamente che abbiamo fatto un test per m> n ore e che il sistema funzionava ancora. Per un gioco, che non è fondamentale per la missione, non è necessariamente necessario catturarlo formalmente esternamente, poiché la maggior parte delle persone probabilmente non incontrerà mai questo problema.
Thomas Owens

8

Non è un bug. Un bug è un comportamento che non è conforme alle specifiche. Se la specifica afferma che il caso d'uso non è un comportamento supportato, qualsiasi comportamento - percepito come valido o meno - in quel caso d'uso è "progettato".

In questo scenario, il gioco funzionante potrebbe essere percepito come un comportamento indefinito.


Questa è una schivata enorme. Lo disprezzo ogni volta che lo sento. Perché viene fuori solo quando "la specifica" è incompleta.
Sean McMillan,

2
@SeanMcMillan: Senza cose del genere, il creep ci ucciderebbe tutti. Ad ogni modo, non è una schivata, perché è uno scenario che è specificamente indicato come non supportato.
Steven Evers,

1
@SnOrfus: è stato sottolineato. Dopo il fatto. Credi davvero che ci sia una specifica che afferma esplicitamente che "Ridurre al minimo l'applicazione per più di x minuti non è supportato"? Chiaramente, è un bug.
ThomasX,

Il problema è che non esistono specifiche sufficientemente complete per descrivere un vero software. Un obiettivo di "corrisponde alle specifiche" non produce un buon software, è solo una scusa che "non è colpa mia" quando qualcosa nel software è male. Forse non vale la pena aggiustarlo, ma "la specifica" non è il motivo.
Sean McMillan,

@ThomasX Considerando che il progetto in cui mi trovo, ha una specifica di 200-400 pagine e ha dei limiti definiti per il runtime. Sì, certamente.
Steven Evers,

5

Se fossi un team di sviluppo guidato da quel progetto, lo definirei un bug ma di minore importanza poiché è ben al di fuori delle normali aspettative operative del software. Se avesse funzionato, probabilmente lo avrei assegnato a un programmatore junior oa un nuovo assunto più come esercizio di apprendimento per loro che per qualsiasi altra cosa.

È una buona idea tenere traccia di questi bug minori poiché possono indicare problemi potenzialmente di portata più ampia. Ad esempio, il bug di salvataggio dei dati che hai riscontrato. Sembra minore a causa di come è successo, ma potrebbero esserci altri casi in cui i dati vengono persi. Usando un sistema di segnalazione bug puoi trovare tutti i casi in cui si è verificato un problema simile e vedere se c'è un elemento comune. In un sistema complesso, documentare questo tipo di cose può aiutarti a trovare bug più seri e sottili.


5

Non sono d'accordo con la maggior parte delle persone qui.

Come ex giocatore di Starcraft (originale), posso attestare che questo è (o era, almeno) un comportamento molto comune. Gli utenti lasciano il gioco il 24/7 per mantenere la loro posizione nelle chat room e unirsi ai giochi quando tornano di nuovo. Sono sicuro che Battle.net aggiornato ha alcuni miglioramenti che possono ridurre la necessità di ciò, ma succede ancora molto.

Avrebbe molto più senso che non ti permetta di partecipare a una partita senza riconnetterti se la tua sessione è in qualche modo, forma o forma, scaduta. Il fatto che ti permetta di unirti ai giochi dopo la scadenza della sessione è un bug per me. La cosa inquietante qui, e qualcosa che non è ancora stato educato, è che gli sviluppatori devono capire i loro utenti. Questo potrebbe benissimo essere un caso limite, ma è un caso limite per i giocatori molto dedicati che dovrebbero essere impostati per compiacere.

Tecnicamente, possono sostenere che è in base alla progettazione e non è qualcosa che intendono riparare. È ancora un difetto ai miei occhi, che alla fine dipende da loro se lo classificano o meno come un bug. Ciò non significa che i giocatori siano d'accordo.

Ad ogni modo, ho pensato di porre una risposta leggermente diversa da quella che è stata pubblicata finora.


1
In realtà minimizzerei lo schermo per lunghi periodi di tempo se giocassi davvero a Starcraft. Penso che la questione se si tratti di un bug sia irrilevante, ma sembra qualcosa che dovrebbe gestire e mi darebbe davvero fastidio se non lo facesse.
psr

D'accordo - questo dovrebbe essere classificato come un bug, sia esso una priorità molto bassa. Mentre possono dire che "lasciare il gioco ridotto al minimo per lunghi periodi di tempo non è supportato", cosa costituisce esattamente un lungo periodo di tempo? Come fanno a sapere che lo stesso problema non si verificherà se ridotto a icona per 10 minuti? Per lo meno un timeout del gioco dovrebbe essere progettato e implementato che disconnette l'utente se rimane minimizzato per più di x minuti se non intende supportare tali azioni.
Gavin Coates,

4

Un bug potrebbe ragionevolmente essere definito come "qualsiasi deviazione dal comportamento previsto del software".

Chiaramente (ed è il loro software in modo che possano determinare come dovrebbe comportarsi) non hanno mai voluto che il software gestisse questo scenario, quindi non soddisfa questa definizione di bug.

Tuttavia, ciò che direi è, almeno, non ottimale è il modo in cui gestisce questa condizione.

Garbage in, garbage out (ovvero l'utente fa qualcosa di stupido o brutto o inaspettato e di conseguenza succede qualcosa di brutto) è stato considerato uno scarso standard di comportamento. Direi almeno che dovrebbe essere più elegante nel modo in cui gestisce questa condizione.

Quindi non strettamente un bug, ma una cattiva gestione di un caso limite.

Detto questo, se fossi in loro non è qualcosa che probabilmente prenderei in considerazione la pena di risolvere (troppo costoso per un beneficio troppo scarso), anche se potrei menzionarlo al team per riferimento futuro che era qualcosa che avrebbero potuto gestire meglio.


1

La definizione di un bug non ha nulla a che fare con il comportamento del software. Un bug viene definito in base al fatto che il comportamento del software corrisponda alle sue intenzioni. E chi può dire quale fosse l'intento? (Dato che qui ho a che fare con i programmatori, chiarirò la prima frase: non esiste alcun comportamento software che, di per sé, costituisca un bug).

Tieni presente che generalmente un bug è qualcosa che gli sviluppatori software dovrebbero risolvere. Quindi la definizione di un bug si basa su ciò che vogliono correggere. Ad esempio, "lavorare correttamente più del 50% delle volte è una funzionalità che prevediamo di rilasciare nelle versioni future". Si può definire qualsiasi cosa come non essere un bug fingendo che il software non sia mai stato pensato per risolvere quel particolare problema. Quindi, in pratica, ciò che costituisce un bug è una considerazione puramente politica.

(A parte questo, ciò riduce entrambi i modi. Per un cliente che non deve pagare per la correzione di bug ma deve pagare per il nuovo sviluppo "non ha alcune funzionalità che ho appena pensato ma che ho ora deciso è implicito al 100% dalle cose che ho citato "è chiaramente un bug.)


Non è OpenBSD che dichiara che qualcosa non documentato correttamente è un bug, non importa quale sia?
Canageek,

1

Non prenderei in considerazione la possibilità di non disconnettere un bug. È solo un bug se doveva (in base alla progettazione, l'intenzione) disconnettersi e non lo fa. Chiamerei ciò che hai inviato una richiesta di funzionalità.

Detto questo, la perdita di dati dopo la battaglia - che potrebbe essere il bug. Non so molto su Starcraft, ma sospetto che non sia per progettazione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.