the functions aren't co-located. The Internet can facilitate this to some extent. But it's still difficult to show a developer a bug, and talk about it, when everyone is miles apart from each other.
As a software buyer you will want to do some level of acceptance testing no matter what. To make sure you're getting value for your money, your technical people and your users need to be involved in the acceptance. I've known customers who actually allowed the software development firm to write their acceptance tests for them to run-which means that serious bugs and usability problems didn't surface until after deployment. Even a good internal test organization can't completely substitute for customers doing real work. If you can't get access to evaluate or monitor the test plans, you can at least volunteer to be a beta test site. If you find out there isn't a beta test-perhaps because the company no longer has a QA group to support one-this is yet another red flag in this buyer-beware market.
As for the investors, I'd like to remind them of a very old metric. For every $1 you spend fixing a defect in the design phase, you'll spend $10 fixing it in the test phase. And if you skip the test phase, you'll spend $100 fixing it after release. A company that's short of cash doesn't want to find itself with too many defects in the field: those multiples of 100 can add up, while customer trust diminishes. Short-term savings quickly translate to crushing long-term expenses. You wouldn't borrow $1 today, and sign an agreement to pay back $100 in six months, would you?
QA is a necessary and economical part of the software development process. The testing function still costs less than the programming function, and QA engineers already know how to do the testing that developers will never fully cover. Cost-conscious investors, like their cost-conscious customers, won't want to bet the farm on over-pruned QA. Be sure you get a complete answer to your question: Who is doing the testing?