Testing at the end? You can't be serious
Let me start that I don't get into religious arguments, whether it be about New vs. Old Testament, Linux vs. Windows or Agile vs. Everything Else. Those discussions just aren't interesting to me. However, the bigger an application gets, and the more people involved, the more I feel that test-driven development is absolutely essential to building something that works. I honestly could care less about most of the tenants of XP or agile, but TDD has saved my life.
And I do get why people are skeptical. The gig I just started has a lot of people skeptical about unit testing in general, mostly because it's considered an afterthought. It really is a cultural shift. People think it's more work, but no one can ever ask the fundamental question, "How do you know the change you made didn't break something you haven't thought about?"
When I first started a gig at Big Ass Auto Insurance® as a consultant, they were buying into everything agile. The paired programming thing annoyed me, and I hated it, but the test-driven stuff fascinated me. Here you could fire off the tests from the entire solution, testing tens of thousands of lines of code, and if something you did broke something, you knew about it. In fact, if you didn't run the tests, the continuous build process would tell you that something was broken. Without this testing facility in place, you had to rely on poor metrics like a lack of compile errors, peer reviews that assume someone in the room knows the rest of the system, etc.
This doesn't even get into the trouble that is test bias. You can't write unbiased test code if you've already written the code. You're too close to it. While unit testing assumes you're doing thorough tests and driving the design of your classes from those tests, it still gives you confidence your stuff works.
Now regarding the waterfall methodology, most of the instances where I've been around it, it fails, or delivers low quality software. Again, I'm not religious about any one methodology, but anyone who has written one line of code knows that stuff comes up, and specifications frequently have to change. I don't know why people try to fight that. Keep the stakeholders involved at all times and the change management is tolerable. That's one of the things I like about a more iterative process, is that you can refactor to a place that you get what you want and need, not what you thought three months ago you wanted and needed.