Você deve levantar até mesmo bugs triviais
Algumas das melhores empresas se tornaram o que são através da atenção aos detalhes.
Existem um monte de séries famosas sobre Steve Jobs quando ele estava no comando, sobre sua natureza vaidosa. Por exemplo, como ele iria debater durante meia hora sobre o tom de cinza para os sinais dos banheiros nas lojas da Apple.
Outro exemplo é a forma como ele “tocou” Vic Gundotra (ex vice presidente sênior, social do Google) em casa em uma manhã de domingo para que ele soubesse que o tom de amarelo do logotipo do Google estava errado no iPhone, mas que ele já havia colocado um engenheiro da Apple imediatamente para trabalhar nisso.
Todas essas coisas aparentemente triviais juntas criam uma percepção mais ampla de uma empresa para seus clientes.
Levantar bugs triviais é prestar atenção aos detalhes. Mesmo que os clientes nem percebem algo tão pequeno que está errado, a partir de um conjunto dessas coisas pequenas, você pode surpreende-los com produtos extraordinários.
Você deve levantar bugs triviais mesmo que você não vá resolve-los imediatamente, desta forma você pode manter uma lista de bugs conhecidos os quais irá liberar em produção e pode decidir por corrigi-los um dia.
Você não deve levantar bugs triviais
O problema de ficar levantando bugs triviais é que isso diminui sua velocidade e tira seu foco de outras coisas, ou seja, da construção de novas funcionalidades para entregar aos clientes.
“Você me ouviu bem. Um foco obsessivo na qualidade pode ser algo ruim.”
~ Jason Fried em, a importância do rápido e sujo.
Se você foca seu esforço na correção de 100% de todo problema identificado em sua aplicação você nunca irá entregar algo, ficará continuamente tentando torná-la perfeita. Ao corrigir um bug trivial você pode acabar descobrindo outros bugs triviais e o ciclo começa de novo.
Na hora que você libera sua aplicação, um bug trivial pode nem mesmo importar tanto assim, até porque, pode estar em uma funcionalidade que nem mesmo será usada. Mas você só pode descobrir isso liberando seu produto em produção, com bugs triviais e tudo mais.
Minha opinião:
Devemos avaliar cada contexto em busca do que agrega maior valor às partes interessadas.
Para aplicações que visam solucionar problemas que na verdade ainda são hipóteses, por exemplo, não é tão arriscado serem liberadas com alguns bugs triviais. Por outro lado, para aplicações críticas, cujos problemas aparentemente triviais podem fazer uma empresa perder muito dinheiro, tais bugs devem estar no radar e sempre que possível devem ser corrigidos.
Um exemplo prático: Imagine um e-commerce em que o carrinho de compras não funciona no navegador Internet Explorer 8 (quem ainda usa IE8? =P) e imagine (hipoteticamente) que somente 1% do público deste e-commerce utiliza tal navegador.
Mas e se esse público de “apenas” 1% representar, por exemplo, 2 milhões de possíveis compradores?
“A população brasileira atualmente é de aproximadamente 200 milhões de habitantes, portanto, 2 milhões de pessoas são 1% da população brasileira.”
Ou seja, caso o público alvo do e-commerce acima citado não suporte o navegador IE8, este poderia (hipoteticamente) perder a chance de vender para 2 milhões de possíveis pagantes por produtos.
Já em um segundo exemplo, pode fazer sentido não corrigir um bug trivial:
Caso existe um sistema de abertura de chamados técnicos em uma empresa com 100 funcionários e, também no IE8, não seja possível abrir estes chamados, mas somente o computador do único estagiário da empresa possua tal navegador (coitado do estagiário =P). Neste caso, 1% significa só o computador deste estagiário. Ou seja, pode não valer a pena o esforço de fazer tal sistema rodar no IE8, e ao invés disso, pode ser menos custoso simplesmente atualizar o navegador específico para uma versão mais atual.
E lembre-se, nem sempre um bug que parece trivial do ponto de vista de testes ou aplicação, pode ser visto desta forma do ponto de vista de negócios.
TALKING ABOUT TESTING 