[donatj]

> If the QA server is down, the testers are unable to do their jobs, and the team isn’t producing working software. For the QA team, this is a production outage. Fixing it should be a top priority.

Genuine question, does anyone here ITT working in software still have dedicated QA? They laid off all our QA engineers about a year ago, and talking to friends and former colleagues it seems to be the industry wide trend?

FWW I think a good QA person is worth their weight in gold and this has been a horrible mistake. I'm just curious if there are any left.

[ctkhn]

I'm in legacy/finance right now and we have a QA team that we share with maybe 2 or 3 other dev teams. I think our integration testing systems could be a lot more efficient but I think if we had a proper pipeline that truly guaranteed integration testing (right now it feels like a shrug) we would lose the QA team like you did.

[brabel]

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.

[lelanthran]

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.

[stephbook]

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."

[hiAndrewQuinn]

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.

[locknitpicker]

> 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.

[ctkhn]

I think our QAs do pay attention a bit more than that, but some of the things they do flag as issues show (to me) that they don't pay a lot of attention until after we've merged and released or we'd get some of their bugs as requirements on tickets instead of as bugs to resolve between QA deploy and before we go to prod.

[creesch]

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".

[throwatdem12311]

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.

[1dontnkow_]

Oh exactly the same here.

Small company in Germany, QA team with about 5 people. But not all the devs are bad, just some are too comfortable with AI and getting lazy.

[gjvc]

"past"

[maccard]

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

[pydry]

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.

[chii]

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.