A questão é provavelmente muito ampla. As razões pelas quais são infinitas.
JMQ
7
A questão é: enviar com bugs ou não enviar de todo :) :) #
226 Vitor Py
41
Todos os produtos são enviados com bugs.
Joel Etherton
4
Defina BUG. Recentemente, enviamos um produto que não seria instalado. Erro: D
Barfieldmv 11/11
2
Você quer dizer 'bugs conhecidos'?
Ninguém
Respostas:
12
Suponho que você esteja falando de um bug "conhecido" (a questão não tem sentido). Bem, a resposta depende desses fatores:
1) Quem é o usuário e como ele / eles aceita o bug, caso seja encontrado?
2) Qual é o impacto potencial (dano) do bug?
3) É possível atrasar o envio do software para corrigir o erro?
4) Mais importante: o que você espera do seu software? Tempo de colocação no mercado? Qualidade? Deseja ver se seus clientes usam o software por tempo suficiente para encontrar o bug?
mas parece que ele está ciente do erro ... então, nesse ponto, parece que um programador é apenas ser preguiçoso para não corrigi-lo estar ciente disso ...
Kenneth
7
@ Kenneth: Você pode ver assim, mas os produtos precisam ser enviados e sempre terão bugs. Depende da gravidade do erro, se você adiar seu prazo.
Matt Ellen
1
@ Matt, isso é verdade. No entanto, parece-me que na maioria dos casos você não gostaria de enviar conscientemente um produto com grandes erros. Isso significaria que os erros restantes que você conhece seriam menores, que na maioria dos casos seriam facilmente corrigidos ou pelo menos contornados. Você não pode lidar com os erros que você não sabe sobre, mas se o processo de teste está sendo feito corretamente a maioria dos erros devem ser pego ...
Kenneth
1
Talvez meu sarcasmo não tenha sido claro ... mas dizer que é "sempre bom" enviar software com erros é meio irresponsável. É como dizer "sempre haverá assassinos no mundo, então não importa se eu vou matar algumas pessoas".
usar o seguinte
7
@DisgruntledGoat Nem todos os erros são iguais: alguns são soluções fáceis, outros são projetos que destroem desastres. Obviamente, esses devem ser corrigidos. Alguns são erros muito raros, difíceis de encontrar, baseados em circunstâncias incomuns e geralmente difíceis de corrigir sem grandes reescritas. Às vezes, essas pessoas apenas precisam permanecer, pois sua fixação oferece muito pouco valor e o software precisa ser enviado ontem. Tudo sobre análise de custo / risco / benefício.
CodexArcanum 11/03/11
33
É uma decisão de julgamento. Lembre-se, um bug pode ser muitas coisas. Se é uma das principais funcionalidades que não está funcionando, conserte-a primeiro. Se é algo menor que tem um impacto real mínimo ou inexistente nas utilidades do programa, você pode deixá-lo escapar.
Então olhe para ele do ponto de vista de custo / benefício.
Você envia produtos com bugs conhecidos quando o custo total e o risco de consertar o problema superam quaisquer problemas e impactos negativos que possam surgir com o problema do problema.
Portanto, se você tiver um período de teste de duas semanas antes do lançamento e um pequeno bug for encontrado, a questão é ... está corrigindo aquele bug que vale as duas semanas adicionais que uma equipe pode agora ter que gastar para testar novamente o aplicativo e a instalação (um passo muitas vezes esquecido na criação de software)? Qual é o custo para reputação ou vendas se o software está atrasado? As pessoas vão ficar com raiva? Eles podem ficar felizes em viver com um bug menor, se a funcionalidade principal puder ser entregue a tempo.
Os riscos incluem o risco de introduzir um novo problema, não apenas na correção do bug, mas também nas coisas que podem surgir com a criação de uma nova instalação.
O impacto negativo é o tempo e o esforço em lidar com os clientes que relatam o bug e coisas como danos à reputação.
Um erro de digitação na caixa "sobre" é algo que você realmente deve corrigir. Demorará cerca de 0,7 segundos (supondo que ambos digitemos na mesma velocidade). No entanto, se você deixar esse erro de digitação, as pessoas poderão vê-lo . É uma morte instantânea para a confiança dos usuários no seu software, se houver erros visíveis na interface do usuário.
Isso parece certo para mim. Na maioria das vezes, existem alguns erros menores conhecidos em um produto, mesmo quando ele é lançado. Eles tendem a ser coisas muito incomuns e têm um efeito desprezível na operação e uso reais do software ou coisas que a maioria dos usuários nunca vê.
glenatron
3
De fato, erros de digitação em sua interface do usuário quebram a fé na qualidade de um produto (erroneamente, como muitos grandes programadores simplesmente não falam inglês), no entanto, entendo o seu ponto - erros triviais que não causam nenhum dano real e provavelmente nunca virão não valem o trabalho de atrasar um lançamento. Deixe-o como um marcador em 1.01.
Phoshi
Não permita erros de ortografia em seu aplicativo. Francamente, estou mais envergonhado por eles do que um bug real.
ChaosPandion
1
Eu não tenho idéia do que você está falando aboot ...;)
Andreas Johansson
6
Os erros vêm em diferentes gravidades. Em qualquer empresa de software em que trabalhei, classificamos os bugs na ordem de prioridade de P0 a P4.
P0 O software não funciona / trava e pode causar danos aos negócios dos clientes. P1 Ele não está funcionando como projetado e trava de forma consistente na funcionalidade principal. P2 Ele trava ocasionalmente e ou uma parte da funcionalidade lateral pode não funcionar. P3 Algum elemento do software não está funcionando como o problema P4 Cosmetic projetado / esperado.
Eu trabalhei em lugares onde os P4 simplesmente não são consertados porque eles têm um efeito tão pequeno no software.
Eu diria que não há problema em enviar se o seu software tiver problemas com o P3 / P4, eu o colocaria nas notas de versão e observaria que eles estão sendo trabalhados.
Eu nunca lançaria software com um problema de P0, P1 ou P2 que eu conhecia.
É chamado de " Problema conhecido ". Google, Microsoft, Apple, etc, todos os produtos são enviados com bugs, conhecidos e desconhecidos. Tente minimizá-los, mas não espere pela perfeição. Navio rápido, navio frequentemente.
Você não pode enviar software sem erros. O conselho que posso dar é que é sempre melhor dizer ao seu cliente: "Esta versão não pode fazer isso e aquilo, mas vamos corrigir isso" do que a situação em que o cliente diz a você que você tem um bug.
Em uma observação séria, a menos que você seja um programador perfeito com uma configuração de teste perfeita, para testar perfeitamente todos os caminhos de código e, eventualmente, que possam existir, é improvável que você envie um produto sem erros.
Portanto, seja pragmático, se tudo o que você encontrou em seu teste foi corrigido, qualquer coisa extra deve ser corrigida conforme a necessidade.
Contanto que você seja honesto com seus clientes, poderá enviar bugs. Contar a eles sobre todos os erros existentes mostra que você tem um bom conhecimento sobre o seu software e que, de fato, é bem testado (se for ..). :)
Obviamente, a melhor coisa é evitar o envio de bugs.
Do ponto de vista dos consumidores ... Nunca. Meu argumento é que, desde que você saiba que existe um problema grave no software, nunca deverá enviá-lo. No entanto, as forças da natureza (negócios) substituem isso se o ciclo de produção do software está agora no estágio em que pode prejudicar o modelo de negócios e são pequenos bugs que não costumam: (i) comprometer a segurança do software (ii) afetar a usabilidade
Como as pessoas disseram, é uma pergunta muito ampla. Na verdade, isso me leva a uma perspectiva interessante: os chamados "bugs" que você afirma serem apenas as falhas descobertas pelos seus testadores. Poderia haver um número infinito de brechas. Recordei uma história interessante que ouvi de um respeitado professor em um seminário de pós-graduação: quando pessoas em um dos países escandinavos usavam uma máquina de votação do tipo "escrita à mão - reconhecível", certas pessoas invadiram todo o sistema escrevendo código SQL malicioso (que o sistema recebeu como entrada normal).
Outro fator decisivo pode ser como o defeito está relacionado ao seu último lançamento. Se o bug fizer parte de um recurso novo, mas com problemas, a não funcionalidade não representa uma regressão da funcionalidade. Vá em frente e envie.
Por outro lado, se o defeito causar uma perda na funcionalidade existente que é conhecida por ser útil aos clientes existentes, ela deverá bloquear a liberação. Esse lançamento seria um rebaixamento para seus clientes e não atenderia aos seus interesses nem aos deles.
Pode haver tons de cinza nisso. Uma regressão na funcionalidade do núcleo nunca deve sair pela porta. Alguma regressão nos recursos periféricos pode levar os usuários se o release também contiver novas funcionalidades nas quais eles demonstraram interesse. Um defeito obscuro que provavelmente não afeta muitos clientes pode entrar em um release, desde que seja fornecida uma solução alternativa quando isso afeta esses clientes. Defeitos em recursos altamente experimentais que são desativados por padrão de qualquer maneira nunca devem atrasar a liberação.
Respostas:
Suponho que você esteja falando de um bug "conhecido" (a questão não tem sentido). Bem, a resposta depende desses fatores:
1) Quem é o usuário e como ele / eles aceita o bug, caso seja encontrado?
2) Qual é o impacto potencial (dano) do bug?
3) É possível atrasar o envio do software para corrigir o erro?
4) Mais importante: o que você espera do seu software? Tempo de colocação no mercado? Qualidade? Deseja ver se seus clientes usam o software por tempo suficiente para encontrar o bug?
fonte
Tem que estar sempre bem, porque não existe software sem erros.
fonte
É uma decisão de julgamento. Lembre-se, um bug pode ser muitas coisas. Se é uma das principais funcionalidades que não está funcionando, conserte-a primeiro. Se é algo menor que tem um impacto real mínimo ou inexistente nas utilidades do programa, você pode deixá-lo escapar.
Então olhe para ele do ponto de vista de custo / benefício.
Você envia produtos com bugs conhecidos quando o custo total e o risco de consertar o problema superam quaisquer problemas e impactos negativos que possam surgir com o problema do problema.
Portanto, se você tiver um período de teste de duas semanas antes do lançamento e um pequeno bug for encontrado, a questão é ... está corrigindo aquele bug que vale as duas semanas adicionais que uma equipe pode agora ter que gastar para testar novamente o aplicativo e a instalação (um passo muitas vezes esquecido na criação de software)? Qual é o custo para reputação ou vendas se o software está atrasado? As pessoas vão ficar com raiva? Eles podem ficar felizes em viver com um bug menor, se a funcionalidade principal puder ser entregue a tempo.
Os riscos incluem o risco de introduzir um novo problema, não apenas na correção do bug, mas também nas coisas que podem surgir com a criação de uma nova instalação.
O impacto negativo é o tempo e o esforço em lidar com os clientes que relatam o bug e coisas como danos à reputação.
fonte
Os erros vêm em diferentes gravidades. Em qualquer empresa de software em que trabalhei, classificamos os bugs na ordem de prioridade de P0 a P4.
P0 O software não funciona / trava e pode causar danos aos negócios dos clientes. P1 Ele não está funcionando como projetado e trava de forma consistente na funcionalidade principal. P2 Ele trava ocasionalmente e ou uma parte da funcionalidade lateral pode não funcionar. P3 Algum elemento do software não está funcionando como o problema P4 Cosmetic projetado / esperado.
Eu trabalhei em lugares onde os P4 simplesmente não são consertados porque eles têm um efeito tão pequeno no software.
Eu diria que não há problema em enviar se o seu software tiver problemas com o P3 / P4, eu o colocaria nas notas de versão e observaria que eles estão sendo trabalhados.
Eu nunca lançaria software com um problema de P0, P1 ou P2 que eu conhecia.
fonte
É chamado de " Problema conhecido ". Google, Microsoft, Apple, etc, todos os produtos são enviados com bugs, conhecidos e desconhecidos. Tente minimizá-los, mas não espere pela perfeição. Navio rápido, navio frequentemente.
fonte
Você não pode enviar software sem erros. O conselho que posso dar é que é sempre melhor dizer ao seu cliente: "Esta versão não pode fazer isso e aquilo, mas vamos corrigir isso" do que a situação em que o cliente diz a você que você tem um bug.
fonte
quando é uma "característica"! ;)
Em uma observação séria, a menos que você seja um programador perfeito com uma configuração de teste perfeita, para testar perfeitamente todos os caminhos de código e, eventualmente, que possam existir, é improvável que você envie um produto sem erros.
Portanto, seja pragmático, se tudo o que você encontrou em seu teste foi corrigido, qualquer coisa extra deve ser corrigida conforme a necessidade.
fonte
Contanto que você seja honesto com seus clientes, poderá enviar bugs. Contar a eles sobre todos os erros existentes mostra que você tem um bom conhecimento sobre o seu software e que, de fato, é bem testado (se for ..). :)
Obviamente, a melhor coisa é evitar o envio de bugs.
fonte
Frequentemente, é melhor enviar um produto no prazo, com uma lista de problemas conhecidos, do que não enviar.
Uma das coisas no mundo da programação que dá às pessoas confiança em um projeto é se elas têm lançamento agendado e se o cronograma é válido .
É por isso que o Ubuntu lança lançamentos a cada semestre, mesmo que ainda haja problemas em aberto.
fonte
Eu diria que uma boa regra geral é "esse bug é um impedimento?"
Se o erro fizer com que um "cenário do caminho feliz" falhe, absolutamente não o acompanhe.
Se o erro fizer com que um "cenário de tangente ao caminho feliz" falhe e não houver solução alternativa, não o envie.
Se um erro estiver documentado e houver uma solução alternativa conhecida, provavelmente não há problema em enviar esse erro.
fonte
Do ponto de vista dos consumidores ... Nunca. Meu argumento é que, desde que você saiba que existe um problema grave no software, nunca deverá enviá-lo. No entanto, as forças da natureza (negócios) substituem isso se o ciclo de produção do software está agora no estágio em que pode prejudicar o modelo de negócios e são pequenos bugs que não costumam: (i) comprometer a segurança do software (ii) afetar a usabilidade
fonte
Como as pessoas disseram, é uma pergunta muito ampla. Na verdade, isso me leva a uma perspectiva interessante: os chamados "bugs" que você afirma serem apenas as falhas descobertas pelos seus testadores. Poderia haver um número infinito de brechas. Recordei uma história interessante que ouvi de um respeitado professor em um seminário de pós-graduação: quando pessoas em um dos países escandinavos usavam uma máquina de votação do tipo "escrita à mão - reconhecível", certas pessoas invadiram todo o sistema escrevendo código SQL malicioso (que o sistema recebeu como entrada normal).
fonte
Existe algo chamado FMEA (modo de falha e análise de efeitos). É muito útil decidir quando um bug conhecido é importante ou não:
fonte
Outro fator decisivo pode ser como o defeito está relacionado ao seu último lançamento. Se o bug fizer parte de um recurso novo, mas com problemas, a não funcionalidade não representa uma regressão da funcionalidade. Vá em frente e envie.
Por outro lado, se o defeito causar uma perda na funcionalidade existente que é conhecida por ser útil aos clientes existentes, ela deverá bloquear a liberação. Esse lançamento seria um rebaixamento para seus clientes e não atenderia aos seus interesses nem aos deles.
Pode haver tons de cinza nisso. Uma regressão na funcionalidade do núcleo nunca deve sair pela porta. Alguma regressão nos recursos periféricos pode levar os usuários se o release também contiver novas funcionalidades nas quais eles demonstraram interesse. Um defeito obscuro que provavelmente não afeta muitos clientes pode entrar em um release, desde que seja fornecida uma solução alternativa quando isso afeta esses clientes. Defeitos em recursos altamente experimentais que são desativados por padrão de qualquer maneira nunca devem atrasar a liberação.
fonte