Reddit reviews Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (Net Objectives Lean-Agile Series)

Magic is the recommended solution.

In Scrum, the team needs to be able to do all the work necessary to deliver. That always, without exception, includes testing. Hiring good testers is not a bad idea. Putting them in a separate team is a terrible idea. Don't do that.

Even if you have some good testers, most of the testing work will still have to be done by the development team. That is because most of the testing work should be in automated, developer, tests. Unit tests. Contract tests. Integration tests. Component tests. Smoke tests. Etc.

If we run into a bottleneck, one of the best ways we have of dealing with it, is to pull the work forward. Any high performing agile team will learn to be good at ATDD/BDD approaches to defining the work. That means involving developers and testers in specifying the work to be done through examples that are a starting point for (automated) functional tests. In this way we specify the tests first, and execution can be by anyone in the team.

Ideally, though, the developers will implement those tests (along with some of the ones mentioned earlier) and in doing so will build up a base regression test suite as the work progresses. There's more to this, but you can easily find out about that. Try Ken Pugh's book and Seb Rose's books.

As for code reviews, those have the same problem: they become bottlenecks. This is why the early XP teams started doing Pair Programming: the same, and more, benefits, but continuously done instead of an after-the-face process stage. Like testing, code review is not an atomic action.

If you keep doing code-review as a stage in your workflow (there's other ways of doing code reviews), you'll understand from the above that a large part of your testing will already have been done, and is automated. Issues found later, either in the code review, or by a manual/exploratory testing step, should be captured in an automated test, and added to the test suite. That way, the type of chicken-or-egg problem you describe just doesn't occur.

TL;DR: the team is responsible for delivering high quality software at the end of every sprint. They need to do all the work that is necessary for that. This includes testing. Testing should be largely automated, and as such is mostly done by the developers. Testing is a skill, and qualified testers should guide your developers in the tests they write. If we run into a bottleneck, we try and pull it forward in time.