Definição de um bug de software. A Blizzard Entertainment insiste que meu "bug" não é um bug. Eles estão certos? [fechadas]

De acordo com a Wikipediaepdia,

Um bug de software é o termo comum usado para descrever um erro, falha, erro, falha ou falha em um programa ou sistema de computador que produz um resultado incorreto ou inesperado ou faz com que ele se comporte de maneiras não intencionais.

Recentemente, encontrei um "bug" no StarCraft 2 que produz um resultado inesperado: http://eu.battle.net/sc2/en/forum/topic/2868627470

O problema é que, se eu mantiver o StarCraft 2 minimizado por um longo tempo, o jogo não desconectará ou gerará qualquer forma de tempo limite. No entanto, ele se desconecta após a primeira batalha e às vezes também perde os dados do jogo (estatísticas da partida).

Infelizmente, de acordo com a Blizzard:

O jogo não foi projetado para ser minimizado por um período tão longo. (Blizzard) não pode considerar esse comportamento errôneo, já que o StarCraft II não deve ser minimizado por horas.

Então, meu "bug" é realmente um bug?

Para uma equipe de software, um bug é um problema de software que precisa ser corrigido. Nem todos os problemas de software precisam ser corrigidos.

A atualização de software é cara. A Blizzard está lhe dizendo que seu problema é um caso extremo. Em outras palavras, o problema de ponta que você descobriu não é necessariamente algo que eles testaram ou que de outra forma gostariam de explicar. A solução do problema o ajudará, mas com toda a probabilidade não ajudará muitos outros. No entanto, o custo para corrigir o bug pode ser alto. Em vez disso, eles podem investir seus recursos em novos recursos ou até finalizar o Diablo III.

Isso me lembra o gato no microondas , especificamente o caso da Sra. Smith em 1983.

O ponto é que você espera que o produto funcione dessa maneira. Principalmente porque vários produtos similares funcionam assim, ou seja, se você os minimiza por horas e os abre, eles funcionam (embora o oposto não seja tão incomum quanto você imagina).

A sra. Smith sabia por experiência própria que secar seus gatos no forno não os prejudicaria (presumindo-se alguma cautela, é claro). Mais precisamente por experiência que ela teve com todos os fornos que tentou. Ela então assumiu que seria o mesmo para o forno de microondas que lhe foi dado. Esta suposição estava errada. As microondas não são projetadas para secar gatos. Nem os fornos convencionais. Eles simplesmente não matam o gato no processo como um efeito colateral dos processos físicos que empregam para gerar calor.

Agora, como produtor de microondas, você pode colocar uma serpentina de aquecimento e um número de sensores no microondas. O último determinaria se o conteúdo atual é um gato e usaria a bobina em vez de microondas.

Da mesma maneira, para produzir um micro-ondas adequado para gatos secos, a Blizzard poderia criar uma versão do SC2 adequada para permanecer no estado minimizado por longos períodos de tempo.

Pessoalmente, eu estaria disposto a pagar mais por um micro-ondas habilitado para secagem de gatos apenas por diversão (supondo que exista um grande logotipo de adequação para secagem de gatos na frente que eu possa orgulhosamente apontar). Mas eu não ligaria para um jogo que pode ficar minimizado por horas.

O SC2 foi projetado para atender a certos requisitos. Sua expectativa não faz parte disso. Você é livre para medir SC2 em relação às suas expectativas. Mas se a Blizzard inclui ou não todos eles no escopo de seus requisitos é a escolha final deles.

Tudo o que você realmente poderia discutir é que é uma falha de design. O senso comum determina que, a menos que uma fração substancial dos usuários fique confusa com o design ou insatisfeita com ele, isso é bom o suficiente. Tenho certeza de que se um número suficiente de usuários declarar que compartilham sua expectativa, a Blizzard renderia e a incluiria no design. Isso tornaria seu problema um bug real e a Blizzard o corrigia.

Acho que este é um caso de software que não está sendo usado conforme definido pelas especificações. Eles dizem

O jogo não foi projetado para ser minimizado por um período tão longo.

O que significa que eles têm alguma definição em algum lugar do que conta como um "longo período de tempo". Se você minimizar o programa por mais de um "longo período de tempo", ele vai além das especificações e do que eles testaram (supondo que eles tenham formalmente testado isso) e eles não garantem o que acontecerá. Obviamente, seria bom se o manual em algum lugar dissesse "apenas testamos este programa para ser minimizado por períodos de tempo não superiores a 10 minutos. Minimize por mais tempo do que isso por sua conta e risco!".

Então não, não acho que isso seja realmente um bug. No meu escritório, isso seria chamado de "problema de treinamento do usuário" (que eu diria que é uma forma de problema de comunicação , porque nesse caso porque nenhum período máximo para minimizar o tempo foi comunicado ao usuário), pois o usuário é não usando o programa corretamente. Não que isso ajude muito a Blizzard, a menos que eles o coloquem no manual ...

Não é um bug. Um bug é um comportamento que não está de acordo com a especificação. Se a especificação indicar que o caso de uso não é um comportamento suportado, qualquer comportamento - percebido como válido ou não - nesse caso de uso é 'por design'.

Nesse cenário, o jogo funcionando poderia ser percebido como um comportamento indefinido.

Se eu fosse o líder da equipe de desenvolvimento desse projeto, chamaria de bug, mas menor, já que está muito além das expectativas operacionais normais do software. Se fosse para ser trabalhado, provavelmente o atribuiria a um programador júnior ou a um novo contratado, mais como um exercício de aprendizado para eles do que qualquer outra coisa.

É uma boa ideia rastrear esses bugs menores, pois eles podem indicar problemas potencialmente mais abrangentes. Por exemplo, o bug de salvamento de dados que você encontrou. Parece pequeno devido à forma como aconteceu, mas pode haver outros casos em que os dados estão sendo perdidos. Usando um sistema de relatório de erros, você pode encontrar todos os casos em que um problema semelhante surgiu e ver se há um elemento comum. Em um sistema complexo, documentar esse tipo de coisa pode ajudá-lo a encontrar erros mais sérios e sutis.

Eu vou discordar da maioria das pessoas aqui.

Como ex-jogador de Starcraft (original), posso atestar que esse é (ou foi, pelo menos) comportamento muito comum. Os usuários saem do jogo 24 horas por dia, 7 dias por semana, para manter sua posição nas salas de chat e participar dos jogos quando voltarem. Tenho certeza de que o Battle.net atualizado tem algumas melhorias que podem diminuir a necessidade disso, mas ainda acontece muito.

Faria muito mais sentido que ele não permita que você participe de um jogo sem se reconectar se a sua sessão expirar de alguma forma ou forma. O fato de permitir que você participe de jogos depois de expirar sua sessão é um bug para mim. A coisa perturbadora aqui, e algo que realmente não foi abordado ainda, é que os desenvolvedores precisam entender seus usuários. Isso pode muito bem ser um caso de extrema importância, mas é um caso de extrema importância para os jogadores muito dedicados que eles devem definir para agradar.

Tecnicamente, eles podem argumentar que é por design e não é algo que pretendem consertar. Ainda é uma falha aos meus olhos, que depende, em última análise, da classificação ou não de um bug. Isso não significa que os jogadores concordam.

Enfim, pensei em colocar uma resposta um pouco diferente do que foi postado até agora.

Um bug poderia razoavelmente ser definido como "qualquer desvio do comportamento pretendido do software".

Claramente, eles (e é o software deles para determinar como deve se comportar) nunca pretenderam que o software lidasse com esse cenário, para que não atendesse à definição de bug.

No entanto, o que eu diria é, no mínimo, subótimo é o modo como está lidando com essa condição.

Lixo para dentro, lixo para fora (ou seja, o usuário faz algo estúpido ou ruim ou inesperado e algo ruim acontece como resultado) foi considerado um padrão de comportamento ruim. Eu diria que, no mínimo, deve ser mais elegante na maneira como lida com essa condição.

Portanto, não estritamente um bug, mas um manuseio inadequado de um case de borda.

Dito isto, se eu fosse eles, não é algo que eu provavelmente consideraria digno de conserto (caro por pouco benefício), embora eu possa mencionar à equipe para referência futura que era algo que eles poderiam ter lidado melhor.

A definição de um bug não tem nada a ver com o comportamento do software. Um bug é definido com base em se o comportamento do software corresponde à sua intenção. E quem deve dizer qual era a intenção? (Como estou lidando com programadores aqui, vou esclarecer a primeira frase - não há comportamento possível de software que, por si só, constitua um bug).

Lembre-se de que geralmente um bug é algo que os desenvolvedores de software devem corrigir. Portanto, a definição de um bug é baseada no que eles desejam corrigir. Por exemplo, "trabalhar corretamente mais de 50% do tempo é um recurso que planejamos lançar em versões futuras". Qualquer coisa pode ser definida como não sendo um bug, fingindo que o software nunca foi destinado a resolver esse problema específico. Portanto, na prática, o que constitui um bug é uma consideração puramente política.

(Como um aparte, isso funciona nos dois sentidos. Para um cliente que não precisa pagar por correções de bugs, mas precisa pagar por um novo desenvolvimento ", ele não possui nenhum recurso que eu apenas pensei, mas que agora decidido é 100% implícito pelas coisas que mencionei "é claramente um bug.)

Eu não consideraria não desconectar um bug. É apenas um bug se deveria (por design, intenção) desconectar e não. Eu chamaria o que você enviou uma solicitação de recurso.

Dito isto, perder dados após a batalha - esse pode ser o problema. Eu não sei muito sobre Starcraft, mas suspeito que não seja por design.