As QA it’s pretty much a given that you own quality, or at least it was up until my most recent job. At past jobs there has been some over the fence mentality, meaning when features are ready for QA the developers “throw it over the fence” to QA and have nothing to do with it anymore – it lacks collaboration or an ownership fo quality. QA is the last check that needs to be marked before releasing, so QA quickly becomes a hold up when things are tossed their way and QA hasn’t been accounted for in a timeline or priority.

Let’s be honest, that way kind of blows. It’s all I’d known, so switching to a new mentality where everyone owns quality has actually been a big struggle for me. But, when it works it is so much better! There is no over the fence mentality, we are all working as a team. Devs are having QA check out their code on their local machine and run through it – QA is involved from the beginning, from designs to production, and everyone from UX to PMs, to Devs to QA owns quality, as it’s something that the whole team strives for, not just QA.

So, who owns quality? It is going to depend on where you work. I’d err on the side of planning to own it yourself, as QA. Plan to fight for quality and back up the issues you find with risk assessments and knowing how impactful they’ll be. And, try to be involved as early as possible so you can bring up quality before everything has been built, so it’s being thought of as it’s being developed.

Before my current job I’d never seen a design doc or been part of a meeting to go over designs, the new feature, and to collaborate with UX, PM’s, and Devs. Rather, I was given a story after everything had already been decided without QA involvement, with no link to designs, and would have to struggle to piece everything together for new features without designs or thorough acceptance criteria. Where I am now isn’t perfect – I still don’t always get what I need for testing, and have to fight for acceptance criteria – but there will be struggles in one area or another no matter where you work. The point is to learn, grow, and do what you can to improve the process. At my current job that means shifting my mindset to all of us owning quality, and being in an environment that is more collaborative and learning to speak up earlier because I’m actually listened to.

Some companies have actually gotten rid of QA to force developers to test their code and care about the quality. When doing this, they’ve also accepted that their standard of quality will be a bit less (Facebook, Pluralsight, etc) – I’m all for developers caring about and valuing quality, but I prefer working together WITH QA to ensure quality, and to learn how to test their own code better, rather than the drastic measures of sink or swim and me not having a job, haha.