O que é bug em software e por que todo sistema tem algum

Por que até sistemas de bancos e de empresas gigantes, com milhares de engenheiros, publicam correções toda semana? Porque bug não é falta de cuidado de uma pessoa. É consequência de software ser uma construção enorme feita de decisões humanas, rodando em ambientes que ninguém controla por inteiro: navegadores diferentes, sistemas operacionais diferentes, dados que o usuário digita do jeito que quer.

Bug é qualquer comportamento do software diferente do esperado: uma conta que dá resultado errado, uma tela que trava, um botão que funciona no Chrome e não no Safari, uma falha que deixa um invasor ler dados que não deveria. O termo é antigo, a palavra significa “inseto” em inglês, e a história mais famosa sobre ele é real, embora quase sempre contada pela metade.

Em vez de tentar eliminar bugs (missão impossível), times profissionais trabalham para encontrá-los cedo, medir o estrago e corrigir rápido. Os erros abaixo são os que mais atrapalham quem está começando a lidar com eles.

Achar que a mariposa de 1947 inventou a palavra bug

Em setembro de 1947, a equipe que operava o computador Harvard Mark II encontrou uma mariposa presa num relé da máquina. O inseto foi colado no livro de registro com a anotação “First actual case of bug being found”, algo como “primeiro caso real de bug encontrado”. A página está hoje no acervo do Museu Nacional de História Americana, do Smithsonian.

O detalhe que costuma ficar de fora está na própria frase: “primeiro caso real“. A graça da anotação era justamente que engenheiros já chamavam defeitos de bug havia décadas. Thomas Edison usava a palavra em cartas do fim do século XIX para descrever falhas em invenções. A mariposa foi uma piada interna que virou lenda, e a pioneira Grace Hopper, que fazia parte do grupo, ajudou a popularizar a história.

Por que isso importa para um dev júnior? Porque mostra que defeito em máquina sempre existiu. Ninguém espera que você escreva código sem bug, espera que você saiba lidar com eles.

Tratar todo bug como se fosse a mesma coisa

“Deu bug” descreve desde um texto desalinhado até um vazamento de senhas. Separar por tipo ajuda a entender a causa e a decidir a urgência:

Os de segurança merecem atenção à parte. O MITRE publica anualmente a lista CWE Top 25 de fraquezas mais perigosas, com os tipos de falha que mais aparecem em vulnerabilidades reais. Injeção de SQL e cross-site scripting estão lá há anos, e são erros que um júnior pode evitar desde o primeiro projeto.

Reportar “não funciona” e esperar que alguém adivinhe

Um bug só é corrigido rápido quando alguém consegue reproduzi-lo. O relatório de bug (a issue, o ticket) é a ferramenta para isso, e a maioria dos que chegam incompletos custa um dia de perguntas e respostas antes de alguém começar a trabalhar.

Um bom relatório tem:

• Passos para reproduzir, numerados, a partir de um estado conhecido (“logado como cliente, carrinho vazio”).
• Resultado esperado e resultado obtido, separados.
• Ambiente: navegador, sistema, versão do app, dados usados.
• Evidência: print, vídeo curto, trecho do log com a mensagem de erro.
• Frequência: sempre, às vezes, só uma vez.

“O checkout não funciona” vira “no Safari 17, com cupom PRIMEIRA aplicado, o botão Finalizar fica cinza; sem cupom funciona”. Com a segunda versão, metade da investigação já está feita.

Corrigir antes de entender a causa

A tentação é colocar um if que trata o caso específico e seguir em frente. O sintoma some, a causa continua, e o mesmo defeito reaparece em outro lugar duas semanas depois.

// "correção" que esconde o problema
if (total < 0) total = 0;

// pergunta certa: por que o total ficou negativo?
// resposta: o desconto era aplicado sobre o valor já descontado

O caminho mais confiável segue uma ordem:

1. Reproduzir o bug de forma consistente, com os mesmos dados e passos.
2. Escrever um teste automático que falha por causa dele.
3. Encontrar a causa com debugger, logs ou a velha técnica de explicar o código linha por linha.
4. Corrigir a causa, não o sintoma.
5. Ver o teste passar e rodar a suíte inteira para conferir que nada mais quebrou.

Esse teste fica no projeto e impede que o defeito volte, o que times chamam de teste de regressão.

Se você não consegue reproduzir o bug, ainda não pode dizer que o corrigiu. Pode, no máximo, dizer que ele parou de aparecer.

Achar que bug encontrado tarde custa o mesmo que bug encontrado cedo

Um estudo do NIST, o instituto de padrões dos Estados Unidos, estimou em 2002 que defeitos de software custavam à economia americana entre US$ 22,2 bilhões e US$ 59,5 bilhões por ano, e que uma parte relevante disso poderia ser evitada com testes melhores e detecção mais cedo. O relatório do NIST sobre o impacto econômico de testes de software é antigo, mas a lógica continua válida.

Na prática do dia a dia, a escada é fácil de visualizar. Um bug pego pelo próprio dev enquanto escreve custa minutos. Pego no pull request, custa uma rodada de revisão. Pego em homologação, custa reabrir a tarefa. Em produção, custa suporte, reputação e às vezes dinheiro do cliente. Por isso times investem em testes automatizados, revisão de código e integração contínua: não para zerar bugs, mas para que eles apareçam nos degraus mais baratos.

Tentar zerar a lista de bugs em vez de priorizar

Todo sistema em uso tem uma lista de defeitos conhecidos. Times profissionais classificam cada um por severidade (quanto estrago faz) e prioridade (quando precisa ser resolvido). Um erro de digitação na página “Sobre” é baixa severidade. Uma falha que impede pagamento é crítica e para tudo.

Severidade alta nem sempre é prioridade alta

Um travamento total numa tela de relatório que só o financeiro abre uma vez por ano é severo, mas pode esperar a próxima sprint. Um logo errado na página inicial na semana de Black Friday é leve, mas ninguém quer deixá-lo lá. As duas escalas andam separadas de propósito.

Bug que fica para depois

Há bugs que nunca serão corrigidos, porque afetam um caso raríssimo e consertar custaria mais do que o prejuízo. Isso não é desleixo, é decisão consciente, desde que esteja registrada. Já falhas de segurança graves seguem outro ritmo: as distribuições Linux, por exemplo, publicam correções em dias quando uma vulnerabilidade crítica aparece, como o buildbase mostrou no caso da falha no kernel Linux com nota 9,8.

Esconder o bug que você mesmo criou

Esse é o erro que mais pesa na carreira. Todo dev, do estagiário ao principal, já subiu código com defeito para produção. O que diferencia um profissional de confiança é avisar logo, ajudar a medir o impacto e participar da correção. Times maduros fazem reuniões de análise sem culpados (post-mortem) justamente para que as pessoas contem o que aconteceu sem medo.

A recomendação direta para o seu próximo bug: antes de corrigir, escreva em uma frase qual era a causa real. Se não conseguir, ainda não entendeu o suficiente. E para conhecer os outros termos que aparecem nesse trabalho, como debug, teste de regressão e deploy, use o glossário de programação com os termos do dia a dia como consulta.