Software quality isn't a fluke, it is not a magic potion, you can't create a quality product using incomplete, inconsistent, or ill conceived requirements. It can't be created by a superhero in a company. It definitely can't be created by omissions in the design, requirements or functional specifications or agile backlog. Software quality is hard earned.
The space shuttle Challenger blew up on January 28th 1986, 76 seconds into its flight. This wasn't a software failure but a management, engineering and quality failure. There were some software aspects to the problem but they were not critical to the overall failure. Even though engineers voiced concerns, management proceeded with the launch. There are lessons to be learnt from that day for software organizations.
The main lesson here is that a failure begins from the starting point. If there is not enough robust processes in place to take into account not just software failure points but also peoples and teams failure points then it is only a question of time before errors are introduced into the system. In a lot of software, errors are manageable but in others it can be fatal.
It ends where it begins. If it begins badly, it will end badly. If your design process is brilliant but your development processes are immature then this is where your end begins. Therefore expectations need to be set accordingly. Quality is frequently beyond a tester's reach because it is a management and team objective not just a tester's job. To make quality outputs you need quality inputs. Like that old idiom, 'You can't make a silk purse out of a sow's ear'.