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.