That's a good point - we're still doing TDD, just with "human code" instead of computer code. You're correct that they write out explicit test cases for each of the acceptance criteria.
It's not cheaper than developers doing the testing, but it's more wholesome. They will test exactly how a user operates, with no regards for a software's boundaries. If part of the requirement is fulfilled by another team's software, they will test that other team's work. This works great for my team since we are highly integrated with the rest of the enterprise.
The other amazing thing about proper QA testing that automated testing doesn't do so well is that they have the ability to go off script. Working in games the number of times I've built some feature or designed a level and thought I had tested it thoroughly only to have QA break it to pieces is very high! Your assumptions versus the assumptions of QA people and players are very different.
A single, technically proficient QA expert on a team can be an incredible asset. Back that with a larger team to regression, smoke and otherwise test things and you'll not only find a load of bugs but also get early feedback on design.
Automated testing definitely has a place. Libraries are a great example. There isn't really an end-user interface to test, it's not the conglomerate of much code and you basically need a test harness to even run your code. The downside is that you're typically back to only testing your own assumptions.
It's not cheaper than developers doing the testing, but it's more wholesome. They will test exactly how a user operates, with no regards for a software's boundaries. If part of the requirement is fulfilled by another team's software, they will test that other team's work. This works great for my team since we are highly integrated with the rest of the enterprise.