As always mentioned testing is context depended , so the time required will change depending on complexity , regression suite, automated or manual , domain expertise requirements etc.
The success of a good test engineer is in justifying why he/sh thinks the time requirment is "20%" , and the justification should be through fact and figures.
Imagine you have to test a policy that has around 100 combination, you should be able to explain following reasons :
This is a critical system and all 100 combination should be tested
It takes 20hrs to test all the combinations
Why can't the process be automated ?
Aside from how long UAT might take, how is it best to manage the
client's expectations with regards to how many issues may be found
during an alpha/beta stage before the client should be happy to sign
off on the work and it can go live?
Clients confidence is not on the number of issues but on the severity and priority of the issues find . The issues might not be just functional issues but also UI design improvements that you feel as important.
Again all this factors depends on context, what you are testing , what are the scope etc.
The best way is to ,
- Follow TDD , where you start writing test cases in parallel with the development task
- This allows to have all test scenarios to be ready when you get the build for testing
- You can save some good amount of time through this as you don't have to wait for the build to start writing test cases
SO in simple words the answer depends on
"Your team size, expertise, complexity of project, feature, and so many factors. In short trust your engineers have good discussion and ask them how much time they would be requiring to gain minimum accepted confidence on the product"