I worked in teams that had anything from 1 tester per 1 developer through 1 tester per 10+ developers to no testers at all. Each of these was able to release software of expected quality (not each did but that's a different story).
The short answer is of course it depends. However looking through the answers that are already here I found much about cost, type of software and methods of testing while nothing about practices related to building software.
If we think of Quality Assurance the responsibility for quality starts far earlier than testers kick in. Or even better, if your team understand quality assurance you should start talking about a role of tester and not a tester's job. In such environment everyone in the team, especially developers, should fulfill the role of tester.
With such attitude one of key factors would be a set of engineering practices you use to build software:
- Methods like TDD, ATDD, BDD help you to automate testing during development, basing on test scenarios that are possibly close to real usage of the app
- Continuous deployment meaning that you release to production (or possibly close to production) environment as often as possible on one hand forces the team to automate as much important stuff as possible (not only testing) but also make increments small enough that risk and cost of releasing with a bug is typically very small.
- Code reviews and/or pair programming (see a nice comparison of them) help to improve the code quality significantly before it even goes to functional testing.
- Automated testing with tools like TestComplete, Selenium or similar helps you to cover gaps that can't be easily covered with test written in the code and serves similar purpose: fewer regressions, higher quality, less need to test manually.
I know teams that were able to go to 0 testers using such approach. Note: I say about 0 tester jobs, not that no one ever fulfills this role. Pretty much the opposite everyone does.
There is another factor which is crucial, which is expected quality. Not every piece of software is expected to be of the same quality. Another social website can fail with little to no consequences while we definitely don't want to see bugs in military software.
Talking about this it is worth to ask how fast we can fix the problem and the answer may be in continuous delivery I've already mentioned. If we are prepared to update the software instantly the potential consequences of bug sliding through testing won't be as big.
Having said all that, I personally feel safer when someone takes a look at software before releasing it so no matter how automated process we have I prefer to have at least on tester in a team.