I've seen many test approaches and most have been successful, except for one and it was not necessarily a test approach. It was more of the customer over committing to a calendar event, and not focused on the software lifecycle.
The problem was that the customer requirements were never really nailed down upfront, so they became a moving target. Once they were identified, the developer had already committed his team to what they thought the customer would want. Unfortunately, it was not what the customer wanted. So, many meetings and conference calls were scheduled to determine what would be the best get well plan. All of this time ate into the development time and the customer began compressing the test cycle.
Unfortunately, there were many problems with the software because of early decisions and non-decisions regarding requirements. The code rework and moving the development team around introduced errors, but the epicenter of the problem started with the customer. Committing to a schedule without a hardened set of requirements is asking for trouble. No matter the development approach, be it agile or waterfall, one must know the desired outcome by defining the requirements upfront.
When the software finally arrived, the test team was pushed hard to finish on time; on time meaning the artificial date set when everything looked great on day one. I believe the test team lost some where around eight weeks of test time, but they were expected to meet the delivery date despite no relief on testing requirements. Many critical errors were found in the beginning of the testing which obviously elevated the emotions of everyone involved, as we were all beginning to see the train wreck coming. The test lead was doing his best to juggle everything and continue to get his team to focus on their test plan.
At one meeting, the test lead started his update with this phrase, "We cannot test quality into the software." It was brilliant. Without screaming the software was not ready for testing, he put everyone on notice that the software would not be ready for primetime no matter how hard his team worked. You have guessed correctly if you just thought that people took offense to the statement and disagreed that there was a problem. His charts showed another story, as there were critical errors all over the system, which were going to require a patch...a patch was identified before the system was even released. The level of effort was hundreds of hours of development and re-testing of the modules. It was not pretty.
Ultimately, the customer backed off the artificial delivery date, and a patch was delivered and tested. A lot of egos were bruised, as the team had a lot of "can do" attitudes who felt they could do anything when, in reality, they should have been saying NO. It was a great lessons learned for everyone. We're still not ready to laugh about it.