Testing was a bottleneck. Bugs were being discovered by users in production. Obviously, the QA team wasn’t providing any value and changes needed to be made.

I’ve worked at a handful of places where the dedicated QA or Testing team was eliminated. Some organizations claimed to be “shifting-left“, others simply saw testers as a bottleneck which was slowing features from being released.

I’ll be very clear – I think the traditional testing phase of software development is an obsolete practice that never worked well. Uncovering a bug a week or two after it’s been written, when the author of the bug has moved on to some other task completely, is most definitely a problem. I also agree with the principles of shift-left testing (this has been core to Extreme Programming and Lean Development for decades). The people writing the code 100% are responsible for it’s quality.

Of course, the process of testing could not be removed completely from these organizations that removed the “tester” job title. In some cases it moved into the development team’s realm of responsibility. Oftentimes, though, the Product Owner was more likely to take on testing duties. I do not believe that you can fire all of your testers (or worse yet, try to convert them to some kind of TestOps team who “owns” test automation). I do not believe that you can ask your development or product ownership folks to somehow become testers, either.

None of these organizations saw any improvement in cycle time or product quality. I don’t know if they saw any cost savings either, especially considering the fact that developer and product owner salaries tend to be significantly higher than those of testers.

One thing people seem to forget is that testers have very a unique skill set. They are amazing at uncovering unexpected actions that your users will try. Testers ask questions and think about problems in a way that nobody else in an organization does. Exploratory, manual testing is still a critical component to releasing a high-quality product.

This does not mean manual testing should be the primary testing approach though. In fact, I think manual testing is a tiny part of a tester’s role.

So what actually works?

The Organization: Fundamentally, I think that quality has to be an explicit organizational prerequisite. Software quality is owned by developers, but supported by the rest of the team. The team structure and practices within the team need to be aligned around this philosophy. When I say explicit, I mean this is something that is regularly discussed and agreed upon. Every single person should have the same understanding of what it means to release a high-quality product.

This is a drastic cultural shift that takes time, but it is the bedrock needed to make any true improvements in the quality of the software being delivered.

The Team: At minimum, the team should contain fully-dedicated folks in product ownership, development, and testing roles. No floaters. No “shared resources”. The proverbial “three amigos/amigas“.

Feature Envisioning: As new features are being envisioned everyone should be involved. Behavior Driven Development and/or Executable Specifications are wonderful tools for these feature exploration sessions. Not only do these discussions drive strong shared ownership of a feature, but the resulting specifications help.

Acceptance Testing: I love the idea that, prior to features being built, automated acceptance tests are first collaboratively written by developers and testers – ideally directly from the specifications previously written. I’m realistic enough to know that features evolve and change as they’re built, though, and automated implementation of acceptance tests is often better handled towards the end of feature development. The writing of those acceptance tests/specifications should happen before a line of code is written and be what drives feature development.

Feature Development: I’m sure there’s no surprise that I encourage XP software development practices of Test Driven Development and pair programming. These practices have produced some of the highest quality, maintainable code that I’ve ever seen. I’ve written in the past about my distaste for GitFlow, pull requests, branching, and all of those activities that encourage siloed work.

Testing: Most features are best built and delivered in small, incremental chunks. With this in mind, it’s very hard to separate development and testing as two separate activities. As code is being built it is also being tested. Because everyone is involved from the initial feature envisioning, there is a shared understanding of how it should function.

But won’t this slow us down? Isn’t it expensive?

The answer depends on what your organization optimizes for. If it’s trying to optimize developer “productivity” (the amount of time developers are hands-on writing new software), then yuuuuup, this is a very expensive, slow set of practices. Though, I really don’t know how much slower it is than having developers act as testers for each other.

If your organization is trying to optimize cycle time – minimizing the amount of time it takes to get quality software into the hands of users – then this ends up being a very cost effective set of practices. Higher quality, better maintainability, fewer production fires all lead to long term organizational productivity gains.

So we should get rid of the QA team?

In principle, I agree with what all of these organizations are trying to accomplish by eliminating the QA team. And I agree that the concept of a dedicated QA team is obsolete (and never really worked well, anyway). But simply dismantling the team and reassigning the responsibilities of testers to others on the team is a short-sighted organizational cop out.

Building quality into a product from the start requires investing in your teams. Coaching them on new practices. Pushing them into uncomfortable new territory, but providing complete support when they fail along the way. It’s not a quick transformation. It’s not something that can be outsourced.

It takes full organizational support, but the results can be amazing.