Should QA exist?

When I got into software that employer was pretty small (50 people overall I think).

Their approach to QA was to have this be a optional thing the service people could do.

It worked surprisingly well, with the caveat that they never created regression tests.

The employer eventually switched someone from that team to establish these regression tests full time, but they had no programming experience and by the time I left no real progress was done in around 6 month. No idea what came of that, and a few years later they fired a lot of the team

> Note this isn’t because QA is finding issues — it’s because of the back and forth.

But it isn't? Finding and fixing are the major time sinks?

> You’re creating bad behavior for your engineers by not having them responsible for their quality.

What prevents you from maintaining responsibility if QA finds the bug? The thing you're throwing over is the investigation/finding, it doesn't follow that you should absolve the throwers

Sorry yes. If an LLM written unit test fails, then it has to be determined whether the test was wrong or the code was wrong. This is an expense in human oversight, unless of course we believe that LLMs will get it right at a high enough rate that they can be left to code everything themselves completely automatically.

In my opinion, the first mistake this article makes is assuming QA should be a completely separate team. My experience has shown that QA works best when it is an integral part of the engineering team. When you silo QA, you create a "throw it over the wall" dynamic where testing becomes a bottleneck rather than a collaborative process. Instead, they should be managed alongside developers and attend the same meetings.

What I find works best is when the Product Manager, Developer Lead, and QA Lead collaborate on requirements. The Product Manager designs the feature, the Developer focuses on technical design and architecture, and the QA Lead maps out user scenarios, integration points, and edge cases. Together, they define the requirements that constitute a successful feature.

When QA is involved early in the process, they understand and drive exactly how the feature should behave. This ensures that critical cases are considered and potential risks are handled before a single line of code is written.

> Isolated QA should not exist because anything a QA engineer can do manually can be automated.

I almost entirely agree. You'd certainly want a majority of QA responsibilities to fall to devs since that keeps the feedback loop tight. Also with the amount of compute we have you can trivially outpace a typical QA team with a single dev working on fuzz tests and property based tests. If you really still feel the need to outsource then there are cool tools like Antithesis [1] which let you trade money for compute in their complicated fuzz testing suite.

Where that falls apart imo is when your software interacts with hardware in any non-trivial way. Fuzz testing doesn't really work when your system is spinning big and heavy things for example. Real hardware that interacts with the world will always create this gap where the devs don't know how to fully test it. Your systems engineers are best equipped to handle this and ensure certain controls follow the right curves, but they typically don't have the bandwidth or are very inexperienced with software. I think a QA organization _can_ fill this gap and deliver value. But I'd almost always prefer hiring another 1 or 2 system engineers who can work towards this problem full time instead. It's much easier to train someone in software than it is to train them in motor control or sealed systems.

[1] https://antithesis.com/