> Except, the whole point of the test is stress the plane and to have nothing break.
That depends on the type of stress test. Some stress tests are to confirm it acts as expected. Other stress tests are used to determine modes of failure. Good engineering isn't just building stuff to spec and assuming it works, just as good programming isn't just writing code and assuming it works as expected because the compiler doesn't throw any errors.
It's very useful to try to break something and see what happens. That's why engineers provide more stresses than systems are designed for to see what breaks, and that's why programmers sometimes run programs in environments constrained in ways it wasn't meant to run in (no disk space, out of memory, network drop, etc), and run fuzzers.
Very importantly, this hasn't been described as a "test failure."
That was heavily implied:
Sources tell KOMO there was a stunned silence after it happened.
…
an event occurred that forced the test team to halt testing. … The team is currently working to understand what happened and ensure the area is safe for work to continue.
Edit: You're not going to silence the crowd with a successful test and you don't temporarily halt testing because of a successful test.
Edit 2: Seattle Times says this explicitly: This ground test failure is another blow.
Yes, but this isn't the language they'd use if one of the test success criteria was "no door blows out" and then a door blows out.
This is evidenced by their plan to "analyze the door and run the test again." If this were actually a test failure, they'd be "analyzing the door, redesigning a bunch of stuff, and running the test again."
That depends on the type of stress test. Some stress tests are to confirm it acts as expected. Other stress tests are used to determine modes of failure. Good engineering isn't just building stuff to spec and assuming it works, just as good programming isn't just writing code and assuming it works as expected because the compiler doesn't throw any errors.
It's very useful to try to break something and see what happens. That's why engineers provide more stresses than systems are designed for to see what breaks, and that's why programmers sometimes run programs in environments constrained in ways it wasn't meant to run in (no disk space, out of memory, network drop, etc), and run fuzzers.