I sometimes refer to this as the two, four, six, eight rule , where the time allocated to testing is two, four, six or eight weeks, depending on what sounds good on the day the project plan is finalized. The single best thing that could be done in estimating the testing effort is to base it on a defined scope. If requirements are defined early in the project, there is a basis for determining the scope of testing. At the minimum, test objectives should relate to project objectives. At the time the project schedule and statement of work are defined, there should be enough information to estimate testing activities if functions are defined at a quantifiable level.
Testable requirements are a way to estimate tests at a detailed level.
However, care must be taken to estimate all phases and types of testing required for testing a particular requirement, plus the time to plan and evaluate the test, plus the time to repeat the test several times if necessary. There is a practical limit at which you must look at time, cost and people and make a reasoned judgment to achieve a workable balance. Some types of testing, such as usability testing can often be performed by small groups of people. After analyzing the above items, a reasoned judgment can be made to staff a team that is the right size to get the job done no matter how many developers you have. Another way to balance the testing workload is to prioritize the modules or areas of the system to be tested.