Por que todo mundo odeia os bugs?

Ao contrário do que muitos pensam, alguns QAs também detestam eles! A metodologia ágil nos ensinou que fazemos parte da equipe e que a qualidade e sucesso do software é mérito de todos nós. Ás vezes encontrar bugs pode ser extremamente desmotivador pra todos e acabamos nos sentindo mal por esse papel, porém, ele é necessário.

Primeiro, vamos entender isso do ponto de vista do programador: você passou um bom tempo desenvolvendo aquele sistema, passou por bons e maus momentos e criou uma relação tão forte pelo seu código que você poderia casar com ele. 
Então, o seu programa cai nas mãos QA e com o primeiro bug encontrado vem a primeira grande decepção, depois essa decepção vai se transformando em raiva após cada erro apontado. O problema é: essa raiva é de você mesmo por ter errado ou do QA?

“O QA é tipo aquela tia chata que você encontra nas festas de família que gosta de apontar todos os seus erros, você já sente desânimo em encontrar ela e ouvir novamente que você está ficando gordo, careca e que ainda não se casou.”

O ponto de vista do tester: aguardamos ansiosamente a nova versão do sistema, e como na maioria dos projetos ela atrasou um pouco durante o desenvolvimento, agora faltam poucos dias para os testes. Você começa a testar e a rezar para que não encontre nenhum bug e possa ir cedo pra casa. Mas aí vem a vida e diz “Não!”. Você encontra o dito cujo, anuncia a descoberta, sente o rancor de todo o resto da equipe, abre um novo ciclo de testes e se prepara para passar a noite toda testando o sistema.

“O programador é tipo aquele amigo chato que atrasa em todos os compromissos. Você sempre acaba esperando muito tempo até ele chegar, e quando ele chega está tão tarde que você vai ter que engolir a comida/perder o começo do filme/chegar atrasado na festa. Se você reclamar, provavelmente vai ouvir um monte de desculpas esfarrapadas porque ele nunca assume os erros.”

Por que isso acontece? Talvez porque a interpretação do que deveria ser o teste de software não seja feita da melhor maneira.

Veja alguns (maus) exemplos:

- Testes só servem pra encontrar bugs.
Testes devem ajudar a agregar valor, aumentar a qualidade e a confiabilidade do sistema. Encontrar erros não diminui a qualidade do sistema, mas deixar que eles continuem lá, sim!

- Meu programa está 100% livre de bugs.
Aceite que o programa pode conter erros, ele não é perfeito, e nem você. Não leve pro lado pessoal.
Além disso, é preciso considerar, o erro existe quando o sistema não faz aquilo que deveria fazer e também quando ele faz aquilo que não deveria fazer. Nem sempre os erros são encontrados testando exatamente o que está especificado na documentação.

- Este programa foi 100% testado.
No mundo ideal nós queremos testar o sistema inteiro com todas as combinações possíveis, mas na maioria das vezes isso é impossível e inviável. Então saia dessa paranóia e foque nos testes que realmente importam. Estamos mais interessados em qualidade e não quantidade.
É preciso tomar cuidado também com o foco dos testes. Como eu disse no começo, não é a coisa mais legal do mundo achar um bug quando você já estava pronto pra ir embora. Mas você faz os testes com a intenção de encontrar bugs ou de mostrar que o sistema está funcionando corretamente? Essa pergunta parece não fazer sentido, mas pense que, quanto mais cansado e com pressa de terminar os testes, maior a chance de você apenas querer mostrar que o sistema está funcionando e pular testes importantes. 
Quanto maior a vontade de encontrar bugs, maior a vontade de “destruir” o sistema antes que ele seja liberado. E essa é uma das razões do porque o tester encontra muito mais erros no sistema do que o programador, que não se importa em “destruir” o sistema.

- Este sistema fracassou na fase de testes.
Outro problema de ponto de vista. O que é fracasso pra você? Achar 10 bugs na fase de testes ou 5 clientes reclamarem de bugs em produção? (Dica: os bugs em produção são os piores).
Quando executamos um teste e um bug é encontrado, a execução é apontada como “mal sucedida”, como se fosse algo indesejada. Mas para o QA deveria ser exatamente o contrário. Afinal, se o objetivo era encontrar erros o quanto antes, esse teste não deveria ter sido “bem sucedido”.

O livro “The art of software testing” (Glenford J. Myers), faz um analogia muito boa sobre fracasso e sucesso dos testes: imagine uma pessoa indo ao médico por estar com mal-estar a dias. O médico pede alguns exames e o laboratório não encontra nada. Esse exame foi bem sucedido ou mal sucedido? O paciente pagou pelos exames, continua doente e o médico não sabe como diagnosticar. Porém, se o exame do laboratório acusar que este paciente tem dengue, o exame pode ser considerado como bem-sucedido, já que agora o médico pode tratar o paciente da forma correta e antes que ele piore. Nesse caso, considere que o paciente é o nosso programa a ser testado. =D

Leia mais em http://www.thebugfeed.com/2016/11/todo-mundo-odeia-os-bugs.html