Quando a ideologia de QA se torna tóxica: a perfeição nem sempre é o objetivo

Sem QA nossos produtos seriam lixo. Digo isso claramente. A garantia de qualidade salvou projetos inteiros, evitou perdas milionárias e protegeu usuários de erros catastróficos. Respeito profundamente o trabalho de quem se dedica a isso.

Mas também há uma conversa desconfortável que precisamos ter. Em alguns ambientes, certa ideologia dentro do mundo de QA se torna tóxica. Não porque a qualidade seja ruim, mas porque qualidade se confunde com perfeição absoluta. E perfeição absoluta não existe em engenharia.

Este artigo não é um ataque. É um convite para olharmos criticamente para nossas próprias práticas. Falo como alguém que esteve nos dois lados do relatório de bug.

O que é um bug realmente?

Vamos começar com uma definição clara. O ISTQB, que é o padrão de referência em testes de software, define um bug ou defeito como uma imperfeição em um componente de software que pode fazer com que ele falhe ao atender a um requisito.

A palavra chave aqui é requisito. Se algo não está especificado, não é um bug. É uma discussão de design, uma melhoria, uma opinião.

O problema começa quando QA começa a rotular como bug tudo aquilo que eles pessoalmente não gostam. Código que poderia ser mais limpo mas funciona. Uma interface que não segue as últimas tendências mas é utilizável. Um fluxo que leva 200 milissegundos a mais que o ideal mas o orçamento não permite otimização.

Isso não é um bug. Isso é uma preferência.

A ideologia tóxica

A ideologia tóxica em QA é reconhecida por estes sinais.

Reportar como bug qualquer desvio de um ideal abstrato. O QA idealista imagina o software perfeito e mede o produto real contra essa imagem. O produto real nunca vence.

Exigir que tudo seja corrigido antes do lançamento, independentemente do custo ou prazo. O resultado são projetos infinitos, entregas atrasadas e equipes frustradas.

Desprezar decisões de negócio como se fossem ignorantes. Um QA tóxico diz "isso é um bug" quando o product owner decidiu conscientemente deixar algo como está por razões de tempo ou mercado.

Recusar priorizar. Eles querem tudo corrigido, mesmo que o bug tenha impacto menor e afete um fluxo secundário.

Um exemplo real. Trabalhei em uma equipe onde um QA reportou como bug que o botão de salvar estava a 6 pixels de onde o mockup indicava. A diferença não afetava a usabilidade. Nenhum usuário reclamaria. Mas o QA insistiu por três dias. A correção levou dois minutos. O debate levou horas. Essa energia poderia ter sido investida em encontrar problemas reais.

Contexto importa

Nem todo software merece o mesmo nível de qualidade. Um sistema de controle de tráfego aéreo precisa de tolerância zero para certas falhas. Um jogo indie em Early Access pode ter bugs visíveis porque seu valor está na inovação, não na perfeição.

Orçamento é real. Contratar mais QA, automatizar tudo e testar em 50 navegadores custa dinheiro. Alguém paga essa conta. Se o cliente não valoriza perfeição 100%, insistir nela é desperdiçar recursos.

O tipo de software define o limite de qualidade. Uma rede social mostrando um comentário desalinhado não é um desastre. Um sistema de votação eleitoral que conta errado um voto é. A mesma equipe de QA deveria aplicar padrões diferentes dependendo do domínio.

O propósito também importa. Uma ferramenta interna para uma equipe de 10 pessoas não precisa do mesmo nível de polimento que um produto B2C com milhões de usuários. No primeiro caso, os usuários podem tolerar imperfeições. No segundo, uma experiência polida faz parte do valor.

Como Gerald Weinberg escreveu em "Quality Software Management", qualidade é valor para alguma pessoa. Não é um atributo absoluto que vive num vácuo. É uma relação entre o produto e quem o usa.

O custo da toxicidade

Quando QA impõe padrões irreais, a equipe começa a esconder trabalho. Desenvolvedores evitam mostrar progresso até que tudo esteja perfeito. O feedback é atrasado. A confiança se quebra.

A fadiga também se acumula no próprio QA. Perseguir perfeição impossível drena energia. Leva ao burnout. Muitos profissionais deixam a área porque sentem que nunca é o suficiente.

E o produto sofre. Lançamentos são atrasados. Funcionalidades valiosas nunca chegam ao usuário porque alguém insistiu em polir um canto que ninguém olha.

Como um QA deveria ser formado

Treinamento técnico é importante. Saber escrever casos de teste, automatizar, entender a pirâmide de testes. Mas isso não é suficiente.

Um QA bem formado também aprende pensamento contextual. Entendem que o nível de qualidade aceitável muda dependendo do projeto. Sabem a diferença entre um bug real e uma preferência pessoal.

Aprendem a se comunicar. Em vez de escrever "isso está errado", escrevem "de acordo com o requisito X, isso deveria fazer Y, mas faz Z. No entanto, entendo que o prazo está apertado. Como priorizamos?".

Aprendem a negociar. Nem tudo precisa ser corrigido antes do lançamento. Algumas coisas podem ir para um backlog. Outras podem ser documentadas como limitações conhecidas.

Aprendem a ouvir o negócio. O product owner pode ter razões válidas para não corrigir algo. Ouvir não é desistir. É colaborar.

O treinamento deveria incluir estudos de caso onde a perfeição não era o objetivo. Projetos que lançaram com bugs menores e triunfaram. Projetos que morreram porque queriam polir demais.

O equilíbrio

QA não é inimigo da equipe. QA é parte da equipe. O papel deles não é dizer não. O papel deles é informar, ajudar a decidir e proteger o usuário. Mas sem esquecer que o usuário prefere uma funcionalidade nova na segunda-feira em vez de um botão perfeitamente alinhado na sexta-feira daqui a três meses.

Qualidade não é binária. Não existe software sem bugs. Todo software tem defeitos. A pergunta não é se há bugs, mas quais são aceitáveis no contexto atual.

Um bom QA entende isso. Um QA tóxico não.

Reflexão final

Valorizo imensamente o trabalho de QA. Sem eles, este blog falaria de software que não pode ser usado. Mas parte do respeito é poder apontar quando algo sai do trilho. A ideologia tóxica dentro de QA é real. Ignorá-la não ajuda a profissão.

A solução não é eliminar padrões. É incorporar contexto na formação. É ensinar que qualidade é uma conversa, não uma ditadura. É lembrar que software existe para resolver problemas humanos, não para cumprir checklists perfeitos.

Como alguém me disse uma vez em uma retrospectiva, "prefiro um produto que voa e às vezes aterra com força a um produto que nunca decola porque o hangar estava limpo demais".

Referências

International Software Testing Qualifications Board. (2018). ISTQB Certified Tester Foundation Level Syllabus. Version 2018 v3.1.

Weinberg, G. M. (1992). Quality Software Management: Systems Thinking. Dorset House Publishing.

Kaner, C., Bach, J., & Pettichord, B. (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley.

Agile Alliance. (2020). The Agile Testing Manifesto and Principles. https://www.agilealliance.org

Böhm, B. W. (1981). Software Engineering Economics. Prentice Hall.