
Stress tests are all the rage these days, but to engineers stress tests are old acquaintances.
It is always difficult to place your project into a stress test – you poured your heart and soul into it, and all you really want to do is protect it and treat it gently so it doesn’t break… Which is of course silly – you should test your brakes in an empty parking lot, not in the middle of traffic.
The difference lies in that you are not really emotionally invested in your car’s brakes… Your project, in contrast, having consumed a fair chunk of your life (and money) over several years, is now practically your child… So there it is – this week, the teams will be stress-testing their kids.
Spaceward’s role is a bit easier. We’re stress-testing our helicopter-tether system, but for us it is very clear that we want everything that can possibly fail do so this week rather than in July… So as much as possible we’ll rehearse and test every aspect of the games. Our goal is to be in a position where the July games are simply a repeat performance of the test. This will of course not 100% possible, but we hope to get close to this goal.
Take for example the camera crews that will film the operations from nearby. Obviously we can run the tests without them, right? Except that if we do that, we’ll have a group of people at the anchor in July who are totally unfamiliar with what’s going on – not a good idea. But they don’t really need to shoot video, right? They can just pretend – why should it matter if they produce video? Except that the camera vans transmit in the MW band that’s awfully close to some of the teams telemetry channels. A climber might work perfectly well when the TV van is just hanging out at the anchor pretending to go about its business, but then be completely non-functional in the real games, since the TV van is now transmitting for real.
These interactions are also old engineering acquaintances, and at NASA Dryden the people are well aware of the importance of testing comprehensive systems. Once you bring the system together, there’s no guarantee that it will perform in exactly the same manner as the sum of its parts. Regrettably, life often makes the ideal test impractical – it might be too expensive, or just physically impossible. So project managers always have to walk the line, make these types of decisions, and then live with the consequences – projects that are too expensive, or tests that are never perfect.
Another complication is that while end-to-end tests are the best for detecting flaws and preventing malfunctions, component-level tests are best at providing detailed performance data.
Engineering is not a black-and-white field. The key to a successful project is to keep a cool head, always take time to think things over, and not try to “gamble” just because you are anxious to see success.
Especially in stress-test week, success lies not in flawless execution, but in finding all the faults. We expects to find faults, and will be happy knowing that each fault we caught, is yet one more fault that will not happen in the games in July.
Here’s to a successful stress-test week.






For the obvious reasons, I invariably get too busy to blog exactly when things get interesting...