Sem baseline não há falha, só opinião

Testes e Bugs são Relativos (toda verificação precisa de referência explícita para reduzir atrito, amadurecer o processo e tornar métricas de defeitos realmente úteis).

Testes e bugs são relativos porque todo julgamento de correção, usabilidade ou conformidade acontece por contraste com uma referência: um requisito, uma regra de negócio, um critério de aceite, uma norma técnica ou um contrato de experiência esperado, sem o qual o veredito é só palpite.

Quando a discussão sobre qualidade ignora a referência e vira uma disputa de percepções, o que se instala é ruído: os times decidem a posteriori, os gestores perdem previsibilidade e o processo se fragiliza, como tantas vezes se observa quando qualidade é tratada como etapa e não como disciplina transversal.

A primeira consequência prática é simples: nenhum teste deveria ser executado sem uma base de comparação, ainda que mínima, porque o resultado avaliado sempre é “obtido versus esperado” (e o esperado precisa existir de forma clara, verificável e acessível).

Mesmo em investigação exploratória, a observação “isso parece errado” é, na prática, um confronto com um pressuposto funcional ou de experiência prévio, o que exige torná-lo explícito para que haja aprendizado e não apenas impressão subjetiva.

Idealmente, a referência é escrita, versionada e conhecida: critérios de aceite, regras funcionais, requisitos não funcionais, padrões de UX e normativas de segurança fornecem o terreno comum onde times concordam sobre o que significa “passar” ou “falhar”.

Quando isso não acontece, decisões variam por pessoa, sprint ou contexto, e a organização entra na espiral cara de retrabalho e discussões intermináveis sobre defeitos que não deveriam existir ou que sequer são defeitos à luz do que foi realmente especificado.

O mesmo raciocínio vale em dobro para o que se chama de defeito: um bug só é bug quando viola uma baseline reconhecida; sem essa ancoragem, o que parece erro pode ser comportamento deliberado, uma degradação aceita, um trade-off técnico ou simplesmente uma história ainda não refinada.

Formalizar a referência no próprio artefato de defeito (apontando requisito, critério de aceite, regra ou norma quebrada) reduz atrito, acelera análise e aumenta a transparência do projeto, porque transforma o debate de “gosto” em verificação de conformidade.

Considere o caso que circulou no LinkedIn: uma QA executou uma busca por termo inexistente na loja do Mercado Livre e classificou como “falha” o fato de, em vez de “nenhum resultado encontrado”, surgir uma lista de produtos aparentemente aleatórios, decisão tomada sem referência explícita do produto ou do negócio.
Sem conhecer a estratégia da plataforma (se o objetivo é não gerar “dead ends” e oferecer alternativas para manter o engajamento e a descoberta), não há como cravar “bug” sem uma baseline validada com o time de produto, o que transforma um parecer técnico em mera inferência.

Do ponto de vista de processo, documentar a referência no upstream (discovery, protótipos, critérios de aceite, padrões de UX, requisitos de riscos, normativas etc.) muda o jogo, porque desloca o esforço para prevenção e alinhamento, e não para arbitragem ex post facto.

Essa consciência executiva sobre qualidade como disciplina transversal tem efeito cascata: melhora briefing, refina escolhas técnicas, eleva maturidade e dá previsibilidade às entregas, sem desresponsabilizar o teste, mas tornando-o parte de um sistema coerente.

Há também um ganho incontornável em métricas: densidade de defeitos, taxa de escape, índice de retrabalho, análise de causa-raiz e quaisquer indicadores de qualidade só são confiáveis se os registros de bugs estiverem ancorados em referências claras e estáveis.

Quando a referência é difusa, contam-se maçãs e laranjas sob o mesmo rótulo, e a gestão toma decisões em cima de números bonitos porém inúteis, algo frequente quando há dívida de especificação e de teste sistemático.

Para tornar isso operacional, alguns hábitos mudam a cadência: cada teste passa a declarar explicitamente seu esperado e sua baseline; cada bug referencia o item quebrado; cada métrica se apoia nessas chaves para permitir cortes por funcionalidade, regra, critério, contexto e fase de detecção.

Com o tempo, a organização descobre histórias nos defeitos e transforma dados de falhas em estratégia de qualidade, em vez de apenas gasolina para o incêndio da próxima sprint.

No fim, a provocação é direta: não existe teste absoluto, nem existe bug absoluto: existe confronto disciplinado entre comportamento observado e uma baseline acordada, que precisa ser visível para todos os envolvidos.

Quando essa referência vira hábito institucional, o debate esfria, a previsibilidade sobe e a qualidade deixa de ser um campeonato de percepções para voltar a ser um sistema de trabalho orientado por evidências e por decisões conscientes.