Stability is very important. At the same time it is hard to control. Team members learn a lot over the period of time in a clients project. Not every detail (lesson learnt) is documented. The team members know the pattern and the rhythm at which the work need to be done for a client. All this knowledge is lost, if the member leaves the team.

Regardless, ANY team should be able to complete some kind of test pass, with results that indicate some kind of subjective or objective measurement of "quality". It doesn't matter here how you define quality; even if everybody on this thread has a different understanding of "quality", you still have some "data" about the code/product quality.

If the code quality did not meet expectations, the quality bar, the contractual obligations about some arbitrary means of measuring the delivery of working software, whatever -- if the quality was not acceptable, somebody in a process management role should have stepped in. That's not on the testers, even if they were experienced QA engineers with technical competency. That's on somebody who is responsible for strategy and business relationships.

The blame here is on management for not acting on the information at hand, and, assuming the client was in the loop, on the client for not insisting on quality deliverables.