Ask HN: Do you have a dedicated QA team?

At my current company they recently got rid of our QA resources. They were contractors and reassigned to do assist in other projects. However, the company now believes developers don't need QA since they can do their own testing. Devs should write code, do all their unit, int, system testings, run their code reviews, save testing artifacts, and work with key stakeholders across the company to close requirements gaps etc. We're basically the entire sdlc minus devops.

This is great for small features, but it gives me pause for mid or large features. Are we the only ones doing this?

This seems to be a pretty common setup. I’ve heard opinions on both sides about whether it is a good idea.

One of the biggest challenges with it for me is that a dev who is a dev is a very different personality who a dev who manages the entire SDLC.

The former placed in the latter environment is going to be lost and annoyed at all the moving parts. They signed up to write code and to trust that the process would deliver good requirements.

The latter in the former environment is going to be frustrated by all the process. They signed up to really own the product and realize that they really just own a block of a process.

I suspect either can work if you have people suited for each. Switching people between them sounds like a recipe for attrition though.

We didn't use to, but now we do. I think we did a better job when we didn't have the team TBH.

Engineers here used to be the ones testing out the code, verifying their changes on pre-production environments, and keep an eye on the deployed code in production to make sure it's working well.

Now I get a sense that engineers do the work up to the point of where QA steps in, and throwing it over to them and moving on. The QA team is new, and so not very well versed in the product, and rely on the engineers a great deal on how to test things, which I get the feeling also ends with the QA team not going out of their way to test things the engineers didn't explicitly say to test. I think it may be playing out in a way where our quality assurance could get worse, and our engineers will end up being less well-versed in the product, and feel less responsibility for delivering quality, while also requiring another team to manage, and spreading work over different people. As a disclaimer I think we may just have a not great setup more-so than saying all QA is bad.

The most common pattern I've seen, which dovetails with this analysis, is that new features are thus treated as more important as long as there is a path around existing bugs. Bugs gets treated as technical debt, and given as much priority.

The best QA setup I've seen was a parallel one. Devs and QA were given the same requirements doc, and independently worked out their assumptions and implementation. QA was often ready before dev work was done so sometimes devs could even run their tests locally to see if they pass. It was really remarkable. It's frustrating its not so clean usually.