To wait until the appln is ready will ultimately lead to an ad-hoc testing approach and not a systematic one..
A design doc would and should provide the tester adequate insight of what one could or should expect.So a thoughful and procedural approach would be to follow with a requirement analysis -test plan- test procedures- test cases-testing( manual or automated).
We start our test case planning and creation once we get the requirements (to reiterate what was said above). But we also start testing at this time. We review and test the requirements, which I'm sure many on this forum do too. Better to find a bug at this point - much cheaper to fix.
Personally, requirements review is my absolute favourite sort of testing. Yet I have heard many people I work with basically say "I don't know how this is going to work, I guess we'll find out when we get the program." Sounds like you'll run into this attitude as well. It's a difficult to change this attitude - I'm not sure I've been successful at changing it yet (but then again, that's not my job!)
Maybe others in this forum can help on how to change that attitude?
For us, we can prepare and complete the test plan as soon as we wish, and conduct a formal meeting with developer, once they agreed and sign off the test plan is considered completed.
However, test plan allows to be changed from time to time with minor issues. For example, a few line of codes need to be changed in order to improve performance. If Design changed then we will considered that's a new project and start from the beginning.
But we are functional QA and not application QA. I know that our Application QA have a different testing strategies.
How many ways can I break your code
IBM Certified Database Administrator
Sun Certified Java Programmer
Oracle Certified Associate
Is there a reason that they want to wait? Perhaps if you do a bit of 'education' as to the benefits of working on test planning prior to receiving the app, it will help.
In addition, I agree completely with the recommendation to 'test' the requirements and design documentation. This is especially critical on outsourced projects. Audit the documentation to be sure the software they are designing is going to meet the requirements of your company. Audit the documentation to be sure the requirements are testable - are they written in such a way that it makes sense to begin test cases?
In my experience, when an application is outsourced, there is a limited time frame (3-6 weeks) for "Acceptance Testing" of the application by your organization. Talk to someone who has seen the contracts and SLAs, because in many cases, defects not found during this period become the responsibility of your company - *especially* if you are responsible for ALL testing. Make sure to plan testing in such a way that you'll be able to complete all of the necessary activities during whatever timeframes are listed in the contracts.