Estou cansado de encontrar bugs

Lucas Amaral
Oct 30 · 5 min read

Este texto é uma tradução livre do artigo original “I’m Tired of Finding Bugs” de Alan Page

Venho atuando na área de testes de software por mais de 13 anos e estou cansado de encontrar bugs. Não é que eu considere que encontrar bugs não tem importância — Eu prefiro muito mais encontrar antes que o cliente o faça. Certamente, também, não estou cansado de testar, no entanto, o objetivo de testar não é encontrar bugs. O testador é responsável por exercitar a aplicação, o produto, reportar informações e muitas outras atividades. Encontrar bugs é um efeito colateral.

Estou cansado de testadores encontrarem muitos defeitos que deveriam ter sido encontrados muito mais cedo, ou mesmo nem ser introduzidos na aplicação. Nós encontramos muitas issues muito tarde no ciclo de vida do produto e deixamos com que muitos bugs cheguem até o usuário final. Eu não quero mais encontrar bugs, quero preveni-los de acontecer.

Eu não quero mais encontrar bugs, quero preveni-los de acontecer.

Leio muito sobre testes de software, mas livros, blogs, artigos e outros materiais parecem focar primordialmente em abordagens para encontrar bugs. Técnicas populares como testes exploratórios ou suposição de erros (error-guessing), podem ser ferramentas efetivas, mas seu foco é em “Encontrar”. Estas e outras abordagens que primariamente pretendem descobrir erros que já estão no código estão tentando alcançar qualidade através de testes. Em outras palavras, tentam “testar a qualidade de um produto.”

Quase todos os livros de engenharia de software tem um gráfico que demonstra como o custo de corrigir erros aumenta quanto mais tarde o erro demora a ser encontrado no ciclo de desenvolvimento do software. Se todos concordam com isso, por que não estamos fazendo mais para encontrar bugs mais cedo? Muitas equipes de engenharia estão começando a envolver testes (e testers) mais cedo no ciclo de desenvolvimento, e acredito que esse seja um bom movimento. Já ouvi os gritos de “vamos direcionar/empurrar a qualidade para cima” (“Let’s drive quality upstream!”) por anos, mas continuo achando que não estamos próximo o suficiente.

Como podemos alcançar níveis mais altos de qualidade e encontrar menos bugs nos estágios mais avançados do desenvolvimento? A maioria dos esforços para “direcionar a qualidade para cima” envolvem a revisão de especificações pelos testers a fim de criar casos de testes ou modelos a partir das especificações ou protótipos iniciais. Estas são abordagens, certamente melhores que esperar o código ser “jogado por cima do muro” para o time de testes. No entanto uma solução consideravelmente melhor seria prevenir que os bugs aconteçam. Com o crescimento da complexidade dos softwares, alguns bugs são inevitáveis — mas a maioria é evitável.

Bugs existem porque alguém cometeu um erro: A pessoa escrevendo os requisitos pode ter esquecido um detalhe, um desenvolvedor pode ter cometido um erro de escrita ou uma chamada errada a uma biblioteca pode ter sido feita. Erros humanos podem ser prevenidos? Certamente sim. Shigeo Shingo, um engenheiro industrial japonês inventou o conceito de Poka-yoke (“evitando erros inadvertidos”). Em uma planta industrial, poka-yoke pode ser implementado introduzindo uma sinalização em uma peça que corresponda unicamente a outra de encaixe, de tal forma que se evite consumo de tempo com posicionamento ou encaixes errados.

Todos os dias, eu encontre dúzias de sistemas aplicados para prevenir erros humanos. O fusível de um equipamento elétrico previne que haja uma sobrecarga no meu equipamento e se inicie um incêndio. A pia do banheiro possui um pequeno buraco para evitar a água de transbordar. Meu exemplo favorito é o meu novo carro que não tranca se a chave estiver dentro.

Técnicas de prevenção são, da mesma forma, aplicáveis a software. Certa vez trabalhei em um projeto no qual registrei uma porção de erros em vários componentes que usavam uma função de uma biblioteca incorretamente. O erro era fácil de acontecer e não provocava uma bug trivial, mas causava um memory leak que ocasionava um erro de performance considerável. Após detectar o problema, escrevi um script para verificar todas as ocorrências do mesmo erro no código fonte. Uma vez que esses bugs foram documentados, adicionei esse script a uma lista de verificações a serem feias quando um desenvolvedor adiciona código à aplicação. Se não evitei a primeira ocorrência desse bug, por outro lado, com o script, demos um jeito desse bug nunca mais voltar a aparecer na aplicação. Mais adiante, por causa das verificações realizadas, os desenvolvedores aprenderam a usar corretamente a função da biblioteca.

Após o sucesso dessa iniciativa, sempre que encontrávamos um bug que poderia ser detectado automaticamente através de códigos, escrevíamos uma rotina e transformávamos a detecção em uma prevenção adicionado essa rotina à lista de verificações. Quando o produto foi lançado, existiam dezenas de scripts de verificação prevenindo centenas de bugs.

Técnicas de prevenção não precisam ser ferramentas. Recentemente estava trabalhando em um projeto no qual havia uma quantidade relevante de erros relacionados a projeto/arquitetura num time de uma área específica. Não conseguiria eliminar os erros através de uma detecção automática, no entanto, estava convencido de que uma revisão de código informal teria percebido estes erros. Mostrei os erros ao gerente da área e ele concordou com minha avaliação. Logo depois ele iniciou a requerer revisão de código para todas as novas alterações de projeto. Após isso, vi pouquíssimos erros de projeto daquele time. Melhor ainda, outros erros que eu não teria encontrado também foram prevenidos.

Prevenção de defeitos definitivamente exige investigação da causa raiz do bug. Existem muitas formas de determinar a origem de um incidente, no entanto tive uma grande sucesso usando uma estratégia muito mais simplificada de análise. A melhor parte da minha técnica é agir como uma criança de 3 anos de idade, perguntando tantos “Porquês” quantos forem necessários para chegar ao ponto no qual posso aplicar a técnica de prevenção: Por que esse bug aconteceu? Por que essa função em particular foi usada? Por que foi possível que essa função fosse usada incorretamente? Por que esse erro não foi pego no Code Review? Posso garantir que essas perguntas irão desvendar uma técnica de prevenção para cada bug, e cada técnica de prevenção que você encontrar e implementar reduzirá significantemente os erros que você irá encontrar em momentos posteriores.

Software continuará a ter bug nos anos vindouros. Posso aceitar esse fato, mas não posso aceitar o grande número de bugs que permitimos — e esperamos — que os testadores encontrem. Se queremos levar Qualidade a sério, é tempo de nos cansarmos de encontrar bugs e começar a preveni-los de acontecer em primeiro lugar.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade