[devnonymous]

You're applying software testing logic to aircrafts! Think about it a bit. Why does hiding implementation details work with software testing? How is software tested? By trying things and catching/looking for breakage. Breaking things is cheap with software.... And when it is expensive (in terms of time/effort/resources /...) the normal approach is to mock out stuff. Would that also be acceptable for aircraft tests? Should test pilots only test simulations of the cockpit?

There's a whole world out there beyond software engineering and what works well for software does not work well elsewhere.

[bookofjoe]

Excellent explicit acknowledgment that software — bits — are not the same as the real (aircraft in flight, e.g.) world — atoms. As a physician, I am routinely amused by comments on HN implying that the human body is equivalent to software, and that medical procedures are the same as steps in execution of a program on a computer. Which would be true, except for one thing: every meat-based computer — aka body — is uniquely wired, with unknown connection patterns causing identical inputs to produce wildly varying outputs. As yet, there's no app for that.

[salawat]

Pack the engineering elitism up, please. It doesn't help anyone at all, and just leads to flamewar.

I"m a professional tester of things, and a metrology nerd to boot. Yes. It is self bloody evident that different measurements (read: tests) require different methodologies, optimizations, set-ups, and execution procedures.

It doesn't change the fact that you still must do envelope testing to ensure your approach to failure is what your analysis says it is.

Do you take it all the way to destruction? No. However, you take it into every conceivable recoverable error state so you know not just the positive behavior of the system, but the negative ones as well.

With flying in particular, this means you have to be transparent with your test pilots. Wanna know why? They don't make test plans. They fly them. You, as the tester trying to test something should treat them as your test executor.

You are the tester. The asker of questions. Obtainer of data, verifier of assertions, and the one mofo there with the mandate (whether anyone else likes it or not) to hold up the entire show until you get your result, or they fire you, whichever comes first. The firing isn't even a big deal when you know beyond a shade of a doubt the question must be asked. That's the kind of outcome that leads to living forever.

Pilot's aren't software people! They're operators! They expect some things can fail, and that you're giving them the knowledge ahead of time to know what to do to save the aircraft.

Information doesn't magically propagate. It takes effort. It takes someone getting out of their chair and having a chat, sending an email, something.

Software testers definitely have it easy with all those fangled debuggers, and not having to gas up a plane and file flight plans and what not, but that means absolutely jack and squat here where software and hardware integrations were not tested to sufficient rigor.

But we're all just looking for the truth. There was truth that needed to be brought into the light, but wasn't. That's our problem here. We need to get down to the bottom of it, and I don't care what anyone's field of study is if they can shed some substantive light on how to keep something like this from happening again.