A few months ago, I joined a new team as a QA engineer, looking for something new. Instead, I started noticing things I had seen before - testing was pushed to the end and left to QA, where every change had to go through a single person. Engineers weren’t always confident in what they were shipping, sometimes pushing AI-generated code without really reviewing it and expecting QA to catch the issues. Everything felt rushed: people were busy, things were constantly moving, but not really progressing.
Despite all the control, there was still no real quality - critical issues were reaching production at least once a week.
So we decided to run an experiment. For a few sprints, we removed the QA gate and tried a different way of working: no QA column, more testing during code reviews, testing sessions, and more collaboration. The goal was to move away from QA approval toward building enough confidence as a team to ship.
It’s still a work in progress, but one thing became clear quickly: removing the QA gate doesn’t just change the process, it reveals problems it was hiding. In our case, the problem wasn’t how we built, but what we built - unclear requirements and a lack of shared understanding of the product were causing most of the issues. Even small alignment changes already had an impact.
This talk is not a success story (yet!). It’s an honest look at what happens when you start changing how a team approaches testing and how to start making that shift.