The most common view of testing (if it is done at all) is to put it at the end of the project.  The reasoning is that testing must come after building, which has to come after design, which has to come after figuring out what to build.  The project is a BigDesignUpFront effort.

Even though this is standard practice, the testing gurus all teach against it. They say to TestFirst and continue testing through the life of the project.  It should be integrated into software development, not tacked on at the end.  TestFirstDesign takes this teaching to an extreme.

----
The typical approach is to schedule tests towards the end of the project and consume "test" time as the schedule slips on early development tasks.  This is especially costly when testing is required as part of a formal certification process for LifeCritical applications-- as test schedule is reduced, features may have to be ripped out because you've run out of time to test them.  This is the SlipperySlope: resources are pulled from test development to remove features, thus further reducing the capacity to develop tests.  

"Equilibrium is achieved when you spend all of your time explaining why nothing is getting done." -- AuthorUnknown