Test the entire system, end to end. A little while before the scheduled release date, testing it all at once.
Best used in conjunction with doing all the Design first (BigDesignUpFront?). Also fits well with strategies with lots of work ThrownOverTheWall; since that is exactly how the customer is going get the system.
BigBangTesting is left very late in the project, and should be done using the tools you have already built. Invite the Customer to have real humans sit down with the system and test it. That's the best way to find out how good it really is.
For best results, do lots of testing beforehand. To do so will improve the coverage of BigBangTesting. No one likes bad news.
In this situation, a period of time marked "testing" on the project plan is in reality the slack time. It's never intended for real development, because if you design at the very end, you cannot possibly have the time to fix or change the broken pieces.
[BigBangTesting leads to IntegrationHell.] or Nirvana (it's your choice)
Typical argument:
"EVERYBODY KNOWS HOW TO DO THEIR JOBS, BUT NOBODY KNOWS HOW TO DO THE OTHER GUY'S JOB"
Is this an Unavoidable AntiPattern? Absolutely not; TestDrivenDevelopment and ExtremeProgramming expresses each code ability and functional requirement as a test, first. This leads to a flat bug rate, very little debugging, and easy project steering.
See also: SurprisedToFindBugs, AlphaTesting, BetaTesting, ...