Mistakes happen, inevitably – a good system will catch them early enough.

An action item to fix something can never be "don't make that mistake again." You have to make a change to the system to find and prevent the error, not a change to the people in the system.

I hope I'm wrong, and that a bug like this happened purely due to dumb luck. But somehow, I'm doubtful.

OTOH, I'm having a hard time imagining what that "believable" scenario might look like. You hand me Disk Utility to test, and I'm going to do some exploratory testing to cram some large strings in both fields, yada yada, we all know the drill. You know, take a moment or two before hitting the code editor. I'm just grasping to figure out how I wouldn't find this bug in like five minutes. And that's before formal tests start getting written. There's missing a bug, and then there's "maybe testing software isn't for you".

In summary, I very much want to give Apple the benefit of the doubt here, but I'm sure having a hard time of it.

  - enter P as password
  - enter H as hint
  - click “OK”
  - unmount the disk
  - mount it again
  - check that the dialog shows the hint H
  - enter P as the password
  ...

To me, it seems at least as likely that that gets past a tester once as it is that a programmer writes that bug.

It still should be highly unlikely to get throug multiple rounds of testing by multiple testers, though.

A better test description would use a more password-like value for P (say ‘tqbfjoald’) and a more hint-like value for H (‘quick and brown’), decreasing that risk.

Maybe I expect too much, but a tester with any experience is going to use strings like "thePassword" and "theHint" to reduce those brain farts. One doesn't have to test software very long before discovering why using "test", "test" as the respective strings for that dialog will bite you.

I agree with your hypothesis, but it's one of those mistakes I'd expect out of a fresh-out-of-college person, and I would expect those folks to be testing, say, TextEdit and not security-sensitive pieces. But there are so many unknowns that I still reserve judgement. I'd just like to know what piece of the process broke down such that something like this gets out the door.

Thinking of that, this may be an example of a copy-paste bug (https://www.viva64.com/en/a/0068/), where the programmer wrote

   strcpy(&r.password    , &encryptedpassword);
   strcpy(&r.passwordhint, &password);

   strcpy(&r.password    , &encryptedpassword);
   strcpy(&r.passwordhint, &passwordhint);

So which one will it be?

On a more serious note: this really depends on the person in question. Not everyone has that state of mind it takes to be extra wary when you find yourself in a similar situation where it went worng before. I've worked with people who made pretty severe mistakes, were pointed out, nodded 'yes', only to just make the exact same programming mistake a few months later. And again, and again.

We all like the story of "just spent a million dollars training you", but experience tells me that there is absolutely no assurance whatsoever that any random person won't be repeating that mistake in the future.

EDIT: and to be clear, of what tiny bit I know, I blame test more than dev. From the dev side I can see someone making a stupid mistake (that for the record I could just as easily make) swapping the foo with the bar, or some mis-click in IB. But I'm still astounded that this made it out of test without getting caught.