Hacker News new | comments | show | ask | jobs | submit login

Re QA: To quote Dodge (via Deming), "You can not inspect quality into a product."

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.




QA done well is more than testing. It's managing risk and ensuring the process matches your risk tolerance. Car entertainment systems and Car breaking systems can be handled differently because the results of failure are different.


I agree. QA has to inform management, who ought to work with the teams producing (software, widget, service) to address the causal factors of the discovered defects and deficiencies.

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.


This is OK if you can guarantee 100% separation of concerns, but the news reports where hackers were able to take over control systems in the car through bugs in the entertainment system should be a huge note of caution.


I mean the entertainment system ideally should not be connected to the engine/drive train systems. That would be a risk management strategy.


There is difference between entertainment system and infotainment 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.


That’s true, but only part of the story.

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.


Check out the 20/20 report (or maybe it was 60 Minutes) where researchers who hacked into a car brought it to a complete stop on a busy highway (quite idiotically, IMO). Yes, other failures can cause this, but it can still be extremely dangerous.


I am not sure what you mean.

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.


No, the large touchscreen should be single point of vehicle config for most functions. Driving a car right now with totally different screens, controls and designs for audio vs. car settings and it’s nuts.


Isn't the point of inspection so that you can perform a REJECT, based on some rejection rate parameter ( which is chosen by business economic reality )

This is the core of the TQM/Six Sigma theory


If your QA is only doing inspections, they're only doing a fraction of the job. Rejecting the work and performing rework or starting over does not address the causal factors in the system of the rejection in the first place.

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: