5 bugs que um bom QA teria pego antes do deploy
Fuso horário que cobra juros, carrinho negativo, e-mail de teste para a base inteira: 5 casos reais de bugs caros e a lição de QA que teria evitado cada um.
Todo bug que chega em produção conta duas histórias: a do defeito em si, e a do processo que deixou ele passar. A segunda é sempre a mais cara.
O caso extremo virou aula em toda formação de engenharia: em 2012, a Knight Capital perdeu 440 milhões de dólares em 45 minutos por um deploy que reativou uma flag antiga em um servidor esquecido (relatório da SEC). Nenhum dos seus bugs custará isso, mas todos seguem o mesmo padrão: eram detectáveis antes.
Estes cinco casos são compostos do que vemos (e pegamos) em projetos reais. Se algum soar familiar, a lição vem junto.
1. O boleto que venceu no fuso errado
O bug: cliente paga dia 10, sistema registra dia 11. O servidor está em UTC, o Brasil em UTC-3, e a fatura "venceu" três horas antes da meia-noite local. Juros indevidos, cliente furioso, estorno em massa.
A lição: data e hora são a maior fábrica de bugs silenciosos do mundo. Um bom QA testa as bordas do relógio: meia-noite, virada de mês, horário de verão, fuso do servidor versus fuso do usuário. Teste de fronteira não é paranoia; é ofício.
2. O carrinho de valor negativo
O bug: ninguém limitou a quantidade mínima no carrinho. Quantidade -3 do produto X, e o total vira desconto. Combinado com um cupom, o e-commerce paga o cliente para levar o produto.
A lição: desenvolvedor testa o caminho feliz; QA testa o caminho hostil. Valores negativos, zero, campos gigantes, caracteres especiais, cliques duplos. A pergunta profissional é sempre "o que acontece se eu fizer o que ninguém deveria fazer?".
3. O e-mail de teste para 10 mil clientes reais
O bug: ambiente de homologação apontando para a base de produção "só por hoje". O teste de disparo de campanha saiu para a carteira inteira, com assunto "TESTE FINAL AGORA VAI".
A lição: separação de ambientes é controle de segurança, não burocracia. QA maduro valida o isolamento antes de validar a feature: para onde vai o e-mail? De qual base vêm os dados? Integração externa está sandboxed? Ambientes bem desenhados tornam esse erro estruturalmente impossível.
4. O botão que só quebra no celular do cliente
O bug: perfeito no Chrome do desenvolvedor, o checkout não clica no Safari do iPhone antigo, que representa 18% da base. Descoberto três semanas (e três reuniões de "métricas caindo") depois.
A lição: a matriz de dispositivos se define pelos dados de acesso reais, não pelo bolso do time. Meia dúzia de combinações navegador/dispositivo prioritárias, testadas a cada release nos fluxos vitais. É a versão front-end da pirâmide de testes: pouco, mas no lugar certo.
5. A migração que apagou o que não devia
O bug: script de migração testado apenas numa base pequena e limpa. Na produção, com dados legados e casos que "não existiam", a cláusula WHERE pegou mais linhas do que devia. O backup existia; o teste de restauração, não. Oito horas de downtime.
A lição: migração se ensaia em cópia da produção, com plano de rollback executado pelo menos uma vez. QA de dados é tão crítico quanto QA de tela, e muito menos praticado.
O padrão dos cinco
Nenhum desses bugs exige gênio para ser encontrado. Exigem alguém cujo trabalho é procurá-los, com mentalidade adversarial, conhecimento das bordas e processo para chegar antes do deploy. É a diferença entre qualidade como etapa (cara, tardia) e qualidade como disciplina contínua.
É esse olhar que colocamos nos times pelo nosso serviço de Qualidade e Testes: testes exploratórios dirigidos a risco, automação na medida certa e as rotinas que fazem o bug morrer barato.
Qual desses cinco te deu um arrepio de familiaridade? Conta para a IA da Rabelo Digital, aqui no canto da tela, e ela sugere a proteção específica. Sem formulário, sem espera.
Deixe um Comentário