Granted they are different divisions, but after the CST-100 debacle [1], NASA also sent a team to audit them [2]. Some of the off-channel remarks by NASA were striking.
[1] https://aerospaceamerica.aiaa.org/boeing-starliner-error-wou...
[2] https://blogs.nasa.gov/commercialcrew/2020/02/07/nasa-shares...
I can't believe I've read that. There's no saving this company.
Maybe fine for an e-commerce site or game, where the stakes are measured mainly in lost revenue/customers and a team of engineers burning the midnight oil to sort the problem. Not so fine for spaceflight.
I had a safety critical embedded engineer who had worked on everything from weapons systems to automobiles first not have any idea what property-based testing was and then proceed to tell me at length how it was pointless because unit testing is all you need as long as you keep making your units smaller and smaller.
At the time I worked in FinTech and was aghast at what I was hearing as they worked on self-driving. If I had to pin down what made me shift my career path into "cyber-physical systems", it was probably that conversation.
Since making the transition and later founding a company dedicated to testing in that domain, I've heard dozens and dozens of sentiments even more concerning.
I've encountered devs that think this nonsense before, but always assumed that this attitude couldn't be held with systems that are actually critical. I'm a bit less naive now.
Despite how obvious it is with a little outside observer perspective, the "perfect bricks" way of thinking is pervasive because that's how the builders and supply chains are organized.
To leave the analogy behind, any non-trivial component has a testable surface area, but typically has additional modes of behavior associated with internal state, environmental conditions, or other areas that well-meaning unit test writers didn't think about.
I have often found issues in simple caller/callee pairs of two components, both of which are tested, but the caller contains subtle expectations of the callee that the unit tests don't match up with.
Boeing et al seem to be following the "move slow and hide problems so we don't fix anything" mantra.
Counterpoint: SpaceX had to re-learn well-known practices that are so commonplace in aerospace it's shocking they weren't being conducted [1]. One example is more complete material testing on critical components as part of supplier quality control. When they lost a rocket due to this process gap, their solution was to layer on those common QC practices. IMO these are risks that, over time, may turn SpaceX into the dinosaurs they are competing with. (reference to Chesterson's fence is probably apt.)
"Moving fast and breaking things" may be fine, but to the GP's point, it has to be a risk-based decision. We probably shouldn't be aiming to move fast when lives are at risk.
[1] https://spacenews.com/falcon-9-failure-linked-to-upper-stage...
Given the amount of money and lives at risk, this level of process short-cutting is mind boggling.