I think this order of tasks is pretty good (especially because it "plans to throw one away") but incomplete. People (even technical managers) often completely omit testing time from project estimates. It is as if once the code is written the customer can deploy that afternoon.

Testing is done during development so it does not need to be scheduled.

Developers rarely test their own code this thoroughly, especially when they are on a deadline. Even when they do they inevitably miss something or other that's pretty serious.

Testing should not be scheduled because no one knows (or can know) how long it will take ahead of time.

That does not make testing instantaneous. Fred Brooks, author of The Mythical Man-Month (which is published in book form along with other essays of his; I strongly recommend the book) advises that a full one half of project timelines are typically spent on testing, whether testing time is scheduled or not. I have observed this myself to be a pretty good heuristic.

Another mistake people make is not having a test plan, or if they do, not scheduling test plan development! I have found that a test plan can be derived from a thorough design document fairly easily.

Testing should not be scheduled because the customer will get mad and possibly go with another bid.

The best of the three argumento IMO. Try to explain to the customer that testing is vital and that other vendors will spend just as much time on it; it's just that *you* are being up front and honest about it. If that doesn't work try not specifying a delivery date due to indeterminate testing time. Last resort, put an "I told you so" clause in the signoff document.

I've rambled too long. Don't forget testing time!!