We have a QA team but it’s small in comparison to the dev team. We didn’t have one before as we thought automated tests and “good developers” who take testing seriously was enough. Unfortunately, even with extreme automation and huge test suites, our bug count per release was unacceptable. Having a QA team was a big help in fixing that. We have two weeks of testing before a release goes out. But we sell a security product so for us bugs must be far between. If you just deploy web apps and you can update every hour, I guess you don’t need it as much.

Worked for a company with a 3D web application (among other things.)

Those things can't be tested with Playwright et al. So the team had a "every pull request gets an instance like pr143.company.org" pipeline where QA approved. They must still have it.

The other companies tested "on demand."

Yes. We call them BAs and they have deep product knowledge, so they also get used for training, escalated support requests, estimations on effort required in new integrations, etc.

Here in Finland my company has a dedicated testing team that's almost at large at the actual engineering staff. We sell a combined hardware-software stack, though, and it's basically a contractual requirement in our industry. They are very helpful to be on good terms with when working on a given project, they often know ways to work with the gestalt I never would have guessed in a million years.

> Genuine question, does anyone here ITT working in software still have dedicated QA?

A few years ago I worked at a company who had a team of QAs dedicated to do manual acceptance tests. Up until the day where a critical regression went unnoticed and it turned out QAs were going through the test suite without actually checking the behavior. Following that the company got rid of all QAs except the software engineer in testing who was responsible for the whole automated test infrastructure, and instead of QAs the team held test days to go through the same manual test suite while we progressively automated them away.

And the whole process improved all across the board.

We have 2 QA and I’m grateful every day for them. The devs generate slop at light speed but nothing gets passed those guys, they’re fantastic.

Different country probably, here QA is still often part of the team. More often than not as part of a team with a title like "test automation engineer".

Yes. I work in games and we heavily rely on manual QA. Too heavily, really.

My experience is 50/50 - half have dropped them, half still have them.

I also don't find most QA to be worthwhile compared to a good, quality focused dev.

There are several cultural issues with how QA are treated (low pay) and how they think they're expected to behave (e.g. hands off the code, hands off types, hands off unit tests) which make them less useful than a dev who is really good at engineering for reliability.

Where we had good engineering practices and that type of "black box" QA I noticed that product tended to find the majority of bugs, followed by devs, followed by customers, followed by QA.

Only when engineering practices sucked and they were used as a crutch by devs did they really catch a lot of bugs.

Of course, in these days of vibe coded madness they're probably getting more useful, not less.

The problem with QA is that from the POV of management, all they do is find issues and delay releases. If the QA team did their jobs well, then once all of the reported bugs are found and fixed (passes QA), the software runs fine and there are no future problems. This sounds good in theory, but a good release doesn't get the credit it deserves - it's "business as usual".

A buggy release is fine, if it came out faster, and costed less. The bugs in the release can be fixed in the future, and the "heroic" fixes are "creditworthy".

Therefore, over time, the QA team is politically relegated as a "useless" team in the department, and thus given how politics play out, they get sidelined until the entire team is gone.