Por muito tempo o QA foi visto como "a fase de testes" — aquele momento, no fim do projeto, em que alguém tenta quebrar o que os devs construíram. Essa visão está ultrapassada. Qualidade não é uma etapa; é uma responsabilidade de todo o time.
Shift-left: qualidade desde o início
Quanto mais cedo um defeito é encontrado, mais barato ele é de corrigir. Levar a qualidade "para a esquerda" do ciclo significa o QA participar do refinamento, questionar requisitos ambíguos e ajudar a definir critérios de aceite antes de uma linha de código ser escrita.
Prevenir > encontrar
Encontrar bugs é bom. Evitar que eles existam é melhor. Um bom QA gera valor ao:
- Esclarecer regras de negócio e expor casos de borda no planejamento.
- Promover testabilidade no design da solução.
- Construir uma rede de testes automatizados que protege o time de regressões.
- Fomentar uma cultura em que qualidade é de todos — devs testam, POs pensam em critérios, QA orquestra.
O melhor bug é aquele que nunca chegou a existir porque a pergunta certa foi feita na hora certa.
O QA como facilitador
O QA moderno é menos "guardião do portão" e mais facilitador de qualidade. Em vez de ser o único responsável por testar, ele capacita o time: ensina boas práticas de teste, cria ferramentas e dá visibilidade sobre riscos.
Métrica que importa
Contar bugs encontrados é uma métrica enganosa — ela premia o cenário em que muitos bugs chegam ao QA. Prefiro acompanhar defeitos que escapam para produção, tempo de feedback e estabilidade da suíte. São sinais de saúde do processo, não de heroísmo individual.
Conclusão
Minha base científica me ensinou a pensar de forma investigativa e rigorosa — e é assim que encaro qualidade: como uma cultura de perguntas, evidências e prevenção, distribuída por todo o time.
For a long time, QA was seen as "the testing phase": that moment at the end of the project when someone tries to break what the devs built. That view is outdated. Quality is not a stage; it's the responsibility of the whole team.
Shift-left: quality from the start
The earlier a defect is found, the cheaper it is to fix. Moving quality "to the left" of the cycle means QA taking part in refinement, questioning ambiguous requirements, and helping define acceptance criteria before a single line of code is written.
Preventing > finding
Finding bugs is good. Keeping them from existing is better. A good QA creates value by:
- Clarifying business rules and exposing edge cases during planning.
- Promoting testability in the design of the solution.
- Building a network of automated tests that protects the team from regressions.
- Fostering a culture where quality belongs to everyone: devs test, POs think in criteria, QA orchestrates.
The best bug is the one that never came to exist because the right question was asked at the right time.
QA as a facilitator
The modern QA is less a "gatekeeper" and more a quality facilitator. Instead of being solely responsible for testing, they empower the team: teaching testing best practices, building tools, and giving visibility into risks.
The metric that matters
Counting bugs found is a misleading metric; it rewards the scenario where lots of bugs reach QA. I prefer to track defects that escape to production, feedback time, and suite stability. Those are signs of the health of the process, not of individual heroics.
Conclusion
My scientific background taught me to think in an investigative and rigorous way, and that's how I see quality: as a culture of questions, evidence, and prevention, spread across the whole team.