This poster seems to think well of the QA team they had. However,
It doesn't matter how great your QA team is, if the quality isn't in the system the QA team can't put it there. All they can do is tell you that you're making poor quality products, and attempt to inform management (as QA rarely has real authority) who should then act on that and work to improve the system. If quality isn't part of the corporate ethos, then they (QA) will make little difference in the end.
By inform, I don't mean "rat out". I mean, management has to have a learning objective. To understand the system that they're managing (because no one understands it fully, their mental model is different than what's actually happening). QA, along with other sources, inform the model of management who can then work with teams to improve the overall system.
Infotainment systems are increasingly used as primary UI for almost anything on car that is not controlled by steering wheel and pedals and thus has to be able to communicate with almost everxthing that is in the car. Tesla is pretty extreme example of this, but it works this way for most manufacturers.
If the only interaction between the automated systems and the braking system is to apply more braking power and the cars breaks can significantly overpower the engine then nothing the infotainment system can do would prevent the car from coming to a complete stop.
Similarly, if the power steering was limited to applying say 5lb of force to the steering wheel (as felt by someone holding the outer edge) a driver could overpower any steering adjustments with minimal effort.
With just those two choices the risks associated with hacking the car dramatically decrease. Yes, the car could prevent someone moving, but that’s also an inherent risk from engine failure.
Referring to an event where nothing happened does not support a ‘very dangerous’ argument. If you simply mean it’s possible and after that it’s then possible that something bad would then happen then I agree.
I am simply saying it’s vastly lower risk than a car that’s impossible to steer or slow down without causing massive mechanical failure.
This is the core of the TQM/Six Sigma theory
You will always have some product that needs to be reworked or rejected. The goal is to ensure quality at every stage in order to reduce the amount of rework. You don't want to go the way of the old US car companies who had to suffer major setbacks in the market because they were spending gross amounts of time reworking defective cars before they could ship them. I do not have a copy of it in front of me, but one of Womack's books had some numbers. Double digit percentage of time for a car's production was spent reworking the car after it had been made to make it suitable for sale.
Now, a premise of Agile (and Lean) is to improve the feedback loop. This is where testing and other inspections come into play. By doing them more often (run unit tests on check in, reject if any formerly passing tests start failing, for instance) you can address some quality concerns earlier.
But you still have to address the cause of the rejections. If Stage 10 of production consistently requires rework, it's great that you're catching, addressing, and doing the rework right then. At least it's better than after Stage 20. But management has to work with QA to not just inspect and accept/reject, they have to address the systemic causes of the failure.