From a final checkpoint to a shared responsibility
When I began working in technology in 2006 as a test analyst, many companies had a dedicated Quality Assurance department. Its mission was to protect software quality throughout the development process, with a particular focus on planning and executing tests.
That structure made sense in the context of waterfall development. Work moved through predefined stages: requirements were documented, developers implemented the system, and QA validated the result. Test analysts reviewed requirements, designed scenarios, executed test cycles, and reported defects back to development. A new build would arrive, the cycle would begin again, and delivery would wait until the system passed the expected checks.
This model created specialized knowledge and clear responsibilities. It also placed quality near the end of the flow. Problems discovered late were expensive to correct, and the QA team could easily become a queue between development and release.
Agile changed the pace, but not always the mindset
Agile methods shortened delivery cycles and brought different disciplines into the same team. Software was no longer expected to move through long, isolated phases. Teams needed rapid feedback and the ability to release value continuously.
However, changing the process did not automatically change ownership. In many organizations, developers continued to write application code while a smaller number of QA professionals remained responsible for validating it. With several developers producing changes for every tester, verification naturally became a bottleneck.
The phrase “the feature is done; only testing is missing” reveals the underlying problem. If testing is still missing, the feature is not done. Quality cannot be a stage added after implementation; it must be part of implementation itself.
Automation is necessary, but structure matters
Manual regression testing takes time, so automated tests became essential to faster and more reliable delivery. Yet simply appointing one person to automate every scenario recreates the same constraint in a different form.
Writing robust automated tests can require as much effort as writing the feature. When one automation specialist supports several developers, coverage falls behind. Teams automate only the happy path, postpone important scenarios, or accumulate a testing backlog that reduces confidence in every release.
Hiring more automation specialists can increase capacity, but it does not necessarily solve the deeper issue. When application code and test code remain the responsibility of separate groups, knowledge remains divided. Developers may focus only on making a feature work, while testers focus on finding where it fails.
Move from finding defects to anticipating them
High-performing teams treat testing knowledge as a capability shared by everyone. The objective is not merely to catch bugs after they exist. It is to identify risks, ambiguities, and failure scenarios before they become defects in the product.
That shift changes everyday collaboration:
- QA professionals contribute their expertise during discovery and design, not only after coding.
- Developers learn test-design techniques and take responsibility for automated checks.
- Product specialists help clarify business risks and meaningful acceptance criteria.
- The team discusses edge cases before implementation and reviews production feedback together.
This does not eliminate the QA profession. It makes quality expertise more influential. QA professionals become enablers who expand the team's ability to reason about risk, observability, testability, and customer experience.
Collaboration multiplies knowledge
A useful transition begins with people working together on real changes. A QA professional and a developer can pair on test scenarios before coding. They can decide which checks belong at the unit, integration, API, or interface level. During implementation, they can build the feature and its automated protection as one piece of work.
Over time, this collaboration distributes knowledge that was previously concentrated in a few specialists. Developers become better at anticipating failure. QA professionals deepen their technical understanding of the system. The entire team makes better decisions about where automation creates value and where exploratory testing remains essential.
The goal is not for every person to have identical skills. The goal is for specialists to share enough knowledge that quality no longer depends on a handoff.
Quality belongs to the team
The evolution of software testing is ultimately an evolution of responsibility. Waterfall organizations needed a final quality gate. Modern product teams need continuous feedback, automated confidence, and collaboration from the beginning of an idea through production.
Tools and automation are important, but they cannot compensate for fragmented ownership. Sustainable quality emerges when the whole team understands that testing is part of building—not an activity that begins after building ends.
This website is the canonical home of this article and its original English edition. You can also read and discuss the Portuguese edition on LinkedIn.