A very wise professor of mine once stated that testing (by definition) is not a way to find defects, but rather a way to determine the quality of the product.

When I read this post, I had an "Ah yes I know what you mean"-feeling. Testing-after-coding is usually regarded as a negative (or 'destructive role' as so nicely put). The reports from automated test suites such as NUnit usually give a success percentage, whilst the reports I usually receive is in most cases no more than a list of defects. Even better, the defects on these lists rarely relate to some or other feature stated in the requirements documentation. 

Granted, a product near completion will contain a lot of cosmetic bugs and annoyances that are not directly related to the requirements document. It is hardly possible to actually deliver a 100% bug-free product. But please focus on the quality please! If the product does what needs to be done, but crashes when you press Shift+Ctrl+Alt+F7+LMouseClick on the 2nd pixel from above, is that considered a critical defect? I think not and whoever was testing that at the end of the project should be sacked, or congratulated on the fact that he had some spare time because apparently all important work was finished. Unfortunately, this is rarely the case.

Instead, if the dev team has its' planning done right there is always some time available for a bug-squat-week.

Do not misunderstand me: I think those bugs should not be there. But the priority should be on quality assertion.