Create a Mac QA division that gets to decide when the release is ready. Make sure that any public bugs like the root login bug are specifically tested to not regress. For security things, specifically have people who's goal it is to try to break into the computer.
If the extra QA ends up slipping the release date of Mac, fine. Better to slip a date than ship software which breaks users and erodes trust.
Unlike some other commenters, I don't see this as so much of an engineering issue. Bugs are bugs and inevitable; at the end of the day, to ship quality software you have to test it. That's what's missing here.
(Not to say that good engineering practices can't make it easier to reach that quality bar, or that very bad engineering practices can't make it impossible [whack-a-mole phenomenon], but that doesn't seem to be Apple's problem here.)
> Bugs are bugs and inevitable; at the end of the day, to ship quality software you have to test it
No. Testing can never ever hope to give you bug-free products.... coding discipline and relentless pursuit of simplicity in design can.
The question is not why the testers didn't catch the "root with no password" bug - the question is really how it was possible to have it, in the first place.
I disagree. Coding discipline and relentless pursuit of simplicity are great things, but there's no amount of discipline or simplicity that is going to save you completely from bugs. You've got to test. Even mathematical proofs are often found to have errors; even formal methods will have errors in the specification.
I'm sure they test some, & you might well be right, but to me, from the outside, it mostly seems like a failure to test thoroughly that's their main problem.
E.g., the root-login-bug slipping back in is inexcusable. That bug should've entered in a "make sure this doesn't" regress list and be tested every release. Yet, it wasn't.
If the extra QA ends up slipping the release date of Mac, fine. Better to slip a date than ship software which breaks users and erodes trust.
Unlike some other commenters, I don't see this as so much of an engineering issue. Bugs are bugs and inevitable; at the end of the day, to ship quality software you have to test it. That's what's missing here.
(Not to say that good engineering practices can't make it easier to reach that quality bar, or that very bad engineering practices can't make it impossible [whack-a-mole phenomenon], but that doesn't seem to be Apple's problem here.)