Automated testing is the best way to test software these days, but whatever method you use, it depends entirely on the test scenarios. You can only test the things that you can imagine.
The MCAS issues was not so much a software issue as an issue with getting the data from the AOA sensor. The software testing failed to imagine a sensor failure, so they had nothing in place to deal with that.
If I remember correctly, the fix for MCAS sets limits on how much the system can correct. I’m not very comforted by this as a fix, nor by the attitude I read about with the executives flying on a MAX for testing and saying “see, it works”. The fix says “a little, but not too much”? The attitude (IMHO) says they don’t appreciate the seriousness of the task.
The standard is “Must never get it wrong.”
Yes. Also a dedicated testing team that have a huge desire to find a problem.
As you say, "Must never get it wrong".
Even in such situations, there are deadlines, all push to meet them, corners get cut. "good enough" "that shouldn't be a problem"
I work on systems that are in banking. Not AS critical as airplane software by a good margin, but we are talking about money.
The system used a very fast "transport" unit that feed documents (checks or in Europe, giros) from a hopper past a high-speed camera, read OCR lines and did character recognition, ink jet unique numbers on the back of each document, and made desicions on which pockets to send the items to depending on other things at 200 inches/sec.
The team that programmed this (way back when) were kind of the elite programmers. They were proud of the complex realtime decisions that had to be programmed, and all with proprietary hardware, and interfaces to that and other.
So,anyway, the team leader was a guy name Milt. He was like THE expert. He assembled his team often and they went over issues, design and other. This was a project for a customer in europe. One of his folk asked "yeah, but milt, what if there is race conditio and X happens just before Y" (whatever). Milt replied "can't happen, no way".
You probably see where this is going but... The guy argued with him. Back and forth. Finally he gave up, after Milt got a little hot and said "Man I'm telling, if that happens I'll EAT MY HAT!"
The programmer went back to his terminal and coded an error message with the type description simple as "Milt, eat your hat" that would go to the screen that shows all errors.
They test, extensively, send to the customer, everythings going fine and suddenly huge stop in the system with the cryptic message "Milt, eat your hat!"
It happened a LOT. It caused downtime and many problems processing. We'd be in meetings with the customer, and they'd go into their language which we couldn't understand and then hear them disgustedly says "blada blada blada, MILT EAT YOUR HAT"
They sent all kinds of folk, down to where we had bus analyzers hooked up trying to catch a spurious signal.
They found it in the end, but that phrase was legendary for a good many years.
The other takeaway from this, the progammer or folks reviewing the code never changed his comical error message to something like "interrupt from X and Y received, DEADLOCK!" and that also should never happen, but often does.