Yeah, keeping testers in the dark works when you're trying to observe if they can navigate a menubar, not when they're piloting a passenger airliner. Test pilots are often engineers themselves, and (at least in the early days) many test pilots worked on designing the very systems they were going airborne to test.

Test pilots should have been informed about MCAS. It's another variable to take into consideration and another system that needs to be tested. How can anyone be sure it does what it's supposed to do when nobody tried activating it? Imagine how many lives could have been saved had someone had the bright idea to put it on the checklist.

There are two seats in the cockpit. I would have informed one of the test pilot crew, the one not flying. In an emergency that person can take over.

> ... proves to a certain degree that they did not believe the change was a major one or worth mentioning

Yes, what Boeing is saying is that MCAS, being designed to force the new plane follow the flight envelope of the old plane

1/ wasn't an anti-stall system

2/ and therefore wasn't a "security" feature (and therefore, it was completely ok to sell upgrades to that system as expensive options)

During a recent interview, Boeing CEO repeatedly said that no specific training was necessary on MCAS because MCAS is part of the whole plane, and when you're flying the MAX you're using MCAS.

This is indeed the problem: they couldn't even consider MCAS failing -- even as a thought experiment, because if MCAS fails, the MAX isn't a 737 anymore!

It looks like they locked themselves up into an alternative reality that they couldn't escape, until planes started crashing into the ground.

> There is no such thing as 'destructive aircraft testing'

Actually, there is: https://www.youtube.com/watch?v=Ai2HmvAXcU0 "This Boeing 777 wing was tested to destruction, finally breaking at one fifty four percent of the designed limit load."

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.

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.