How to Foster Collaboration Between QA and Dev Teams

One of the most impactful changes I've seen in quality happens when you implement one specific process: a 30-minute QA-Dev sync meeting for each feature before coding begins to discuss the implementation and testing strategy. When I first bring this up with a client, I get predictable objections: Developers don’t want to "waste" their time. Leadership doesn’t want to "lose" development time. Testing is necessary anyway, so why discuss it? Our QA doesn’t couldn't possibly understand code. The reality is that the impact of effective testing can be remarkably hard for an organization to see. When it goes smoothly, nothing happens — no fires to put out, no production issues. As a result, meetings like this can be difficult for leadership to measure or justify with a clear metric. What confuses me personally is why most engineering leaders say they understand the testing pyramid, yet they often break it in two, essentially creating two separate pyramids. Instead, you should have a collaborative session where QA and Dev discuss the entire testing pyramid — from unit tests to integration and end-to-end tests — to ensure comprehensive and efficient coverage. Talking through what constitutes effective unit and integration tests dramatically affects manual and end-to-end testing. Additionally, I'm continually impressed by how a QA who doesn’t "understand" full-stack development can still call out issues like missing validations, test cases, and edge cases in a method. QA/Devs should also evaluate whether any refactoring is needed, identify potential impacts on existing functionality, and clarify ambiguous requirements early. The outcome is a clear test plan, agreement on automated and manual checks, and a shared understanding that reduces late-stage bugs and improves overall product quality. #quality #testing #software

How did the QA Team Miss this? I still remember sitting in a high pressure RCA meeting a few years ago. A critical bug had just gone into production, the client was unhappy, and the tension in the room was hard to ignore. As expected, the question came up: “How did the QA team miss this”? All eyes turned toward me. As a testing lead, the first instinct in that moment is to defend the team. You want to pull up test reports, show what was covered, and explain that everything was executed as planned. But after spending many years in this space, I knew that defending the QA team alone was not going to help. It would create more distance between teams. So I took a different approach. I said, I am not here to defend QA. I am here to understand what went wrong and fix it. I explained it in a simple way. Testers don’t create bugs, we find them which are already in the application. If something made it to production, it means it passed through multiple stages before it reached testing. So the question was not who missed it, but how it got through the workflow. It shifted the focus in the meeting and the discussion and the questions are: Were the requirements clear enough? Did development and testing have the same data? Was anything skipped because of timeline pressure? Did our definition of done cover end-to-end behavior? That shift changed the tone of the discussion. Instead of focusing on QA, we started looking at the gaps in the process as a team. We found that developers were working with different data sets than what we used in testing. A critical peer review had been skipped due to urgency. Our definition of done was focused on completing features rather than validating how everything worked together. That conversation helped any defense ever could. One thing I have learned over time is this. If the culture is about “who missed it”, people will try to protect themselves. If the focus is on “why did this happen”, teams will be working together to improve. Quality is never owned by one team. It will be based on how well everyone works together to build the right thing. QA Touch #softwaretesting #qualityassurance #leadership #RCA #processimprovement #softwaredevelopment #QAstrategy #qatouch #qatouchautomate

New Game Production Q&A today, here’s a question I didn’t get to answer from the last one. From Julian: “What strategies have you found for bringing QA into the active development cycle, when it's traditionally been decoupled and viewed as an "end of development" function?” You know, the biggest thing I see keeping QA as the ‘last in the pipeline’ discipline is that we often silo them away and treat them as if that ‘end of development’ function is all they can do. It’s a low-efficacy view of QA, plus a studio design that even in the org chart has them apart from everyone else. The first thing I’d want to do is start breaking QA analysts out of their silo and embedding them on teams. I’m not kidding, even if you just do that, if you’ve hired QA that can take initiative and care about the quality of the player experience, they will go into teams and meetings and find ways to add value. Next, you want to rethink the nature of QA. If you view them as ‘people that find and report bugs’, the view that their role is all bunched up at the end when the game is ‘done’ can almost sort’ve be badly rationalized. But if you view them as individuals on teams who are responsible for making sure low quality experiences - and I mean the engaged experience of the player, not graphical fidelity or refined UI! - don’t get to players, and as people who are to maintain a deep connection to the quality of the products they are helping deliver, you can start understanding just how valuable the QA function can be. Even at a ‘dealing with bugs’ level, a truth discovered in engineering (and is also true in game dev) is that your time to resolve a bug is directly related to the effort required to solve it. If a QA analyst on a team finds a bug in 6 hours working alongside a designer and engineer on a new bit of gameplay or a feature, odds are that bug will be resolved in a fraction of the time it would have taken someone to puzzle their way through the code and lua 6 months from now while we’re all in a panic trying to ship. Having QA embedded on teams, creating test plans, working to make sure everyone is following your definition of done, advocating for stable builds and regular playtests, and ultimately pushing for whatever is produced to actually land with your audience is an end to end function. It’s ok to put a lot of responsibility on your QA. They’ve worked in a world where all they do is submit reports. They want to be involved. Seriously, in my years of game dev I’ve rarely seen a discipline rise to the challenges put before them more than QA. Massive respect. They can be a much bigger asset to studios than they typically are. Stop wasting the energy and awareness they bring! #gameproduction #gamedevelopment #gameindustry #qaanalyst

Why Should QA NOT Be a Gatekeeper? Have you ever wondered why treating QA as a gatekeeper can be detrimental to the software development process? While QA is crucial for ensuring quality, positioning it as a final hurdle before release can create bottlenecks and foster a culture of blame. Instead, QA should be integrated throughout the development lifecycle, collaborating with developers to prevent defects early on. When QA is involved from the start, they can help identify potential issues during the requirements and design phases, significantly reducing the likelihood of defects later. This proactive approach promotes a shared responsibility for quality across the entire team, leading to more efficient and effective development processes. Furthermore, continuous collaboration between QA and developers encourages a mindset of continuous improvement, where quality is built into the product from the ground up. Shifting away from the gatekeeper model also accelerates the feedback loop, allowing teams to detect and address issues more rapidly. This not only improves the overall quality of the software but also speeds up the delivery cycle, meeting business needs more effectively. Additionally, QA should not have the final say on business decisions but rather make recommendations based on their assessment and risk evaluation, ensuring that informed decisions are made collaboratively. How has your team benefited from integrating QA throughout the development process? Share your experiences and thoughts on fostering a collaborative QA culture!

SDETs are often treated like a service desk, where development finishes a feature and simply throws it over the wall, saying, “QA — go test it.” This leads SDETs to scramble to write automation, log defects, and chase regressions, turning them into firefighters instead of engineers. The hard truth is that this model doesn’t scale. It burns out talented individuals and fails to produce real quality. The best SDETs I’ve worked with excelled not just in writing tests but also in: - Asking tough questions in design meetings - Challenging vague requirements early - Improving how systems were built for testability - Reducing risk before code ever hit main When SDETs are involved early in the process, powerful outcomes emerge: fewer defects, shorter cycles, higher confidence in releases, and stronger engineers across the board. More importantly, this approach fosters growth among team members, transforming test writers into quality leaders, building technical depth, and creating ownership instead of handoffs. Quality should not be an afterthought at the end of delivery; it’s a discipline that must be embedded from the beginning. To achieve better software, stop using SDETs as gatekeepers. Develop them as engineers, empower them as partners, and trust them as leaders. Your product and your people will benefit immensely. #QualityEngineering #SDET #SoftwareTesting #TechLeadership #EngineeringCulture #DevOps #Agile #ContinuousImprovement #SoftwareDevelopment #LeadershipDevelopment #BuildInQuality #ScalingTeams #TechCareers #ProductEngineering #Startups #SaaS

Question: You are a QA lead in your project. Some disagreement happened between QA team & development team over defects logging. How do you handle disagreements between teams? What is your approach to manage such situations? My answer: I would focus on collaboration more to reach mutual agreement between teams as both the teams are working towards the same goal, to deliver a good quality product. Both the teams are putting their best efforts in their day to day work. Real time example: We had a situation where the development team believed the defect I found was either not valid or not reproducible in their environment. In that case, I first reproduced the issue in multiple environments (e.g., different browsers, OS versions) to ensure the bug wasn’t environment-specific. I also used logging to capture any additional data that would support my case. Once I had sufficient evidence, I documented the bug with clear steps to reproduce, attached screenshots, logs, and even a video recording if necessary. I scheduled a meeting with the dev team to walk them through the steps and provided a real-time demo of the issue. I also emphasize the importance of early bug detection during the development lifecycle. Daily stand-ups and close collaboration with devs can help prevent these types of disagreements from escalating later in the cycle. Lastly, we use a bug triage process where both teams come together to assess and prioritize defects based on severity and impact, rather than pointing fingers. This would be my approach to handle such situation. Do you want to add anymore pointers to this question. Please add from your experience. #qalead #qualityassurancelead #testlead

If I gave a TED Talk, my topic would be "How to build a strong QA culture by killing QA." Okay, our goal isn't to actually kill QA. We just want to end QA as a last-minute checkbox component at the end of the development cycle. I strongly believe that quality should be the responsibility of the whole organization – not just the QA team. Obviously devs care about shipping quality software. But the reality is that quality often gets sacrificed on the altar of deadlines, feature pressure, and the relentless pace of modern software development. It’s not that devs don’t care, it’s just that quality isn’t prioritized enough. So here’s how I would change this culture: 1/ Quality as engineering responsibility - Eliminate the "throw it over the wall to QA" mentality. - Cultivate a mindset where quality is everyone’s responsibility 2/ Quality as a first-class citizen - Put quality metrics on executive dashboards next to revenue and growth. - If it's not visible at the top, it won't be prioritized at the bottom. 3/ Quality as technical excellence - Celebrate robust test suites the same way we celebrate create code or architectures. - Make quality engineering a badge of honor, not a burden. 4/ Quality as cultural value - Reward quality-focused behaviors. - Make testing and quality processes part of performance reviews across the entire org. Do that and you’ll have happier devs, a better product and more satisfied customers. btw I’m serious, if anyone wants to invite me to do a TED Talk, I’m so game.

Could pairing a tester and a developer be the most underrated move in QA? Pair testing is a simple idea with big benefits. When a developer and a tester sit together—virtually or in person—they combine perspectives to uncover issues faster. The developer brings deep knowledge of how the code is constructed, while the tester excels at questioning assumptions and exploring unusual angles. That synergy often unearths insights neither would find alone. Plus, it fosters empathy: testers gain an appreciation for the complexities developers face, and developers learn to value the relentless curiosity testers bring. Whether it’s ad-hoc sessions or scheduled collaborations, pair testing can dramatically boost product quality and team cohesion.

👩💻 Dev finishes on Day 8. Sprint ends on Day 10. QA silently asks: “So… high-quality delivery in 2 days?” 😅 🎯 Let’s be real: Testing delays usually don’t come from poor planning — they come from late handovers. So, how do we fix it? 🔄 Collaborative solutions: ✔️ Involve QA from day one — adopt a shift-left mindset ✔️ Share early builds so QA can prep ahead ✔️ Keep communication tight with daily Dev-QA check-ins ✔️ Mark tasks as “done” only when both Dev and QA sign off ✔️ Treat sprint goals as shared goals, not isolated efforts 🤝 Quality isn’t a phase. It’s a shared responsibility. Start early. Test smart. Deliver with confidence. 💥 #SoftwareQuality #AgileMindset #TeamQA #SprintSuccess #DevAndQA #TestEarly #ShiftLeftTesting #QualityFirst #BuildBetter #QALife

The more I learned from developers, the better I became at QA. Here are 3 more lessons. These didn’t come from courses or blogs. They came from working side-by-side with devs every day. • Read their pull requests You don’t need to understand every line. Just seeing how features are built helps you write better test cases and catch issues earlier. • Understand feature flags Many modern teams ship behind flags. Knowing how to test toggled features is key to preventing surprises. • Debug with them Jumping into logs and test failures with developers taught me how to isolate problems faster and improve how I report bugs. QA doesn’t need to sit on the sidelines. Partnering with devs makes us better testers, and better teammates.