To build on what Lobwedgephil mentioned, the problem is more that when you are building tens of millions of a thing, QA gets a little complicated. Do I fully test every single one fully? That adds to the cost of the product, and may not be terribly helpful if the mistake rate is something like 1-3% (on average).
QA for mass production isn't checking 100% of the devices coming off the line unless it can be quick and automatic. Instead it is done via random sampling of batches. So say I produce 10,000 widgets a day, I may test 100 of them at random, or 1%. Assuming enough samples, with a true random sampling, will get you quite a bit of information on how manufacturing is actually going. This is generally the "front-end" of the quality checks, where a company needs to produce 1 million widgets for launch, will randomly sample, say, 1% of them (10,000) for QA. Those 10,000 should not show anything abnormal, and themselves should have no more than ~100 failures. Spikes in failure rates, specific things showing up repeatedly in the failures, etc, all suggest something systemic that is fixable. However, if the failures themselves are small, say maybe 50 failed at a rate of 0.5%, and the failures are seemingly random, rather than systemic, it becomes a question of just how much effort you expend to find the other ~4950 likely defective widgets out of a million. And as a customer, realize that you would be the one paying the cost.
The other part is looking at failure rates. These are devices that are DOA, are exchanged/returned due to defects, or develop problems during the lifespan of the device. But getting it to 0% is surprisingly difficult. This data is used to drive investigations, manufacturing improvements, stocking of repair parts, etc. It's helpful for this cases where your random sampling misses something about a bad batch, or there's something systemic that QA simply cannot catch because it takes, say, 1,000 hours of use before it shows up.
One thing that the internet does is that it's super easy to share information about these failures that can and will make it through QA. This isn't a bad thing, per se, because it makes it a bit harder for a real problem be kept quiet, say a bad batch of produce with salmonella. But it's worth also pointing out that the plural of anecdote isn't data. Anecdotes of people having issues is a useful tool, but the inherent bias involved with self-reporting means it's not an ideal way to gauge how things really are.
Especially when in the case of the iPad, I would bet that there's probably been at least ~5k devices that were bad out of the box for every single iPad launch dating back to 2010, if I assume an early failure rate of about 1-2%. Without knowing how many of those are early adopters that would post on a forum like this one, what percentage of those affected report, etc, etc, and it becomes hard to figure out what the odds are that you would get a bunk device because of these other factors.
