If you don't catch major errors until the QA team has time to do a full comprehensive test of the product then those errors are probably sitting in the codebase for days or weeks, and additional changes are being piled on top of them which will make it harder to identify which commit was the problem. Do a code review and you'll catch a bunch of stuff before it even hits QA.

Correct. Any time you need a completely separate team to handle any aspect of the lifecycle of the product you're introducing delays and miscommunication. Besides, a separate team to do a part of the job scales badly: it needs to grow at least linearly with the number of developers, sometimes superlinearly.

You should absolutely have a small QA team, but their job shouldn't be doing the QA -- it should be helping others do their own QA.

Major errors are easy to spot and will likely take QA minutes to find. They're also probably not going to do a full test of the entire system with every change unless you've got a very small product.

One thing I've seen that I like a lot is individual changes creating individual front ends. You test the one thing in that change, and it's done. This tends to cause a lot of problems with CORS, but then what doesn't?

Agreed with you though that good code reviews (whatever that means) obviates most of this.

The actual job is always fast. What takes time is for the job to sit in the queue outside the QA department. The figurative papers moving between desks is always what kills your efficiency, not people doing work slowly.

I don't see that as mutually exclusive. A QA team can be more effective if you're taking steps beforehand to limit the scope of their work, which means your engineers need to start getting more hands on with that kind of work (code reviews, automated testing, whatever...)

Your quality problems might well come from poor or non-existent architectural decisions and tech-debt, and QA won't pick up on that stuff unless it manifests as a faulty requirement.

The earlier you catch a problem, the easier it is to fix.

Our tests have caught 10s of thousands of bugs. We couldn't move forward without them. Maybe they just fit our use case more than yours.

In our case we have a public API and several backends. The tests run against the public API. To know that a new backend is working it has to pass all the tests. Getting any new backend working correctly without the tests would be nearly impossible.