Quando é bom enviar um produto com um bug conhecido?

Quando é bom enviar um produto com um bug conhecido?

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?

Tem que estar sempre bem, porque não existe software sem erros.

É 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.

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.

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.

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.

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.

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.

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).

Existe algo chamado FMEA (modo de falha e análise de efeitos). É muito útil decidir quando um bug conhecido é importante ou não:

1. Ocorrência
2. Gravidade
3. Detecção

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.