In my 22 years in this industry, spanning the early days of Opera Software to my current role leading 30 professionals at Xogito, I’ve learned one hard truth: traditional hand-over testing is where quality goes to die. I’ve seen the evolution of our field from the time “even before Agiles” became the standard, and the most persistent failure I see is the “throw it over the wall” mindset.
When developers write code and then simply toss it to a tester to “fix the quality,” you are setting yourself up for a cycle of hotfixes and blame. To deliver high-stakes products on time, you must shift to Collaborative Testing. This isn’t just a buzzword; it is a fundamental framework that transforms quality from a final department check into a shared team mindset.
1. The First Pillar: Quality Starts with the Product Owner
The Product Owner (PO) is the vital bridge between business intent and technical execution. In a high-performing team, quality begins at the refinement stage, not the testing stage.
If a PO defines clear user stories with deep acceptance criteria, they eliminate the “question marks” that inevitably turn into bugs. When the whole team sits together to define these criteria before a single line of code is written, the path is cleared of guesswork.
“The quality starts here, not from the tester team, but really starts here.”
Strategic Reflection: Addressing ambiguity early is the most effective way to reduce the massive costs of rework and waste. When requirements are solid, the downstream work is about execution, not clarification. If your PO isn’t your first line of defense for quality, your process is already leaking.
2. The Second Pillar: Developers as Quality Champions
The second pillar is the “Quality-Focused Developer.” This is someone who doesn’t just want to write code and move on; they take ownership of how that code behaves in the wild.
However, we must be honest about the mindset gap. Most developers focus on the “happy path”, ensuring the feature works under ideal conditions. A senior tester, however, brings a mindset focused on complex use cases and edge-case impact that developers often “don’t have a clue about” or simply don’t have the desire to explore because they “just want to write code.”
The goal is to bridge this gap. Quality-focused developers write unit tests and ensure code is testable, cooperating with testers to define test cases early.
Strategic Reflection: When developers prioritize testability, the feedback loop narrows. This proactive cooperation prevents the “ping-pong” effect where tasks bounce endlessly between “In Progress” and “In Testing.”
3. The 3rd Pillar: Manual and Automation Testing are Distinct Disciplines
I view manual and automation testing as two separate roles requiring entirely different skill sets. Treating them as the same job dilutes the effectiveness of both.
- Manual Testers: They are the cognitive engine of the team. They focus on validation and verification, thinking through complex scenarios and real-world user impacts that a machine cannot perceive.
- Automation Testers: Their focus is stability, speed, and accuracy. Their goal is to shorten the release cycle by providing a “trustworthy” regression suite.
Strategic Reflection: Automation’s true value isn’t just “speed”, it’s about freeing up your manual testers to do the high-level cognitive work that automation can’t touch. If your automated tests are flaky, you haven’t built a tool; you’ve built a distraction.
4. The 4th Pillar: The Process is the “Glue”
Process is what aligns your PO, developers, and testers. In one project with 12 people (including three QAs), we faced a cycle of releases followed immediately by critical production hotfixes. We had to change.
We implemented a monthly release structure: three weeks of development and testing, followed by a three-day code freeze. We mandated a Daily Triage, where any problem found was escalated to the entire team immediately. Most importantly, we required that every single task in a sprint be manually verified in a dedicated environment before it could be closed.
Initially, the team resisted. “Everyone hates changes,” and this was no exception. But within a few months of seeing post-release issues drop nearly to zero, the team didn’t just accept the process, they began proposing their own improvements.
Strategic Reflection: A disciplined process is critical for mobile applications (Android/iOS), where you cannot force a user to update as easily as a web app. The process exists to support the team, not to hinder them. If the team sees the value in release stability, they will eventually champion the process themselves.
5. Stop the Blame Game: Quality is a Team Sport
In many companies, the dynamic is unfair: if a release is a success, the developers get the “kudos,” but if a production bug appears, the tester is asked, “How did you miss this?”
This is why I often prefer to remove “Quality Assurance” from a tester’s title. The title implies that one person is “assuring” the outcome. In reality, a tester’s job is to provide information and verification about the product’s state. The team is what provides the actual quality.
“Quality is everyone’s responsibility and it’s a team sport.”
Strategic Reflection: This is the most difficult cultural shift to achieve. It requires developers and POs to understand that they own the outcome. If there is a problem, the team resolves it together. If there is success, the team takes the prize together.
Conclusion: Building Your Own Process
Building a collaborative environment requires you to be a “thinker-doer.” You must define your goals, consider your specific team size, and engage stakeholders early.
Remember, processes are not “carved in stone.” They must evolve as your team matures. If a process stops serving the goal of high-quality delivery, change it.
Final Thought: If your team dismantled the “QA Department” today, would quality remain a priority for every developer and product owner in the room? If the answer is no, it’s time to stop looking for bugs and start building a culture of shared ownership.
