Testing happens on every level, from below ground (think Italy’s Neutrino experiment), on the ground for the mere mortals, in the skies with the latest aeroplanes and drones, and in space. It cannot have escaped you that Boeing has not been having a great time lately, and they currently have their Starliner Capsule attached to the International Space Station (ISS) as part of their third test flight. After the first test flight (20 Dec 2019) encountered issues, Boeing/NASA decided to add another test flight (19 May 2022). The third test flight (5 Jun 2024) has gone only slightly better because it reached and docked with the ISS for an eight-day mission. On the journey to the ISS, several issues were encountered, some of which could have impacted the safe return during re-entry, so further tests and analysis had to take place.
We must remind ourselves that these are test flights and issues can be encountered; that is the prime definition of testing. You analyse the issue, fix it, retest it, and move on. In the confines of space, this retesting is highly constrained; plus, we are talking about two human crew members at risk if things go wrong, which means your test steps must be meticulous. In addition, the spacecraft’s manoeuvrability and fuel are limited in the vicinity of the ISS. From the media, it seems that Boeing (the manufacturer) fully trusts that the fixes applied will be sufficient to bring the spacecraft and its crew safely back to Earth. On the other hand, NASA (the operator) has not been convinced about the test results so far. This is a classic relationship in the software industry, too. Still, if human lives are involved, you follow extremely rigid safety protocols to ensure your employees’ safe operations. This is NASA (renowned for its detailed procedures), and this is rocket science!
While trust in your supplier can be high, even close to 100%, you always apply your own testing/evaluation before using it within your own domain. You might have full access to the supplier’s testing results, which can be an input into risk analysis, but these are never a replacement for your deep analysis/testing. Trust and phrases like “replacement like-for-like” are the wrong attitudes in determining your testing scope; your acceptance should always be based on your requirements or protocols and, as such, should be tested separately. Regarding the Starliner, NASA has taken the next steps carefully and rightfully so. The potential for the capsule to return automatically without its crew, thus posing no danger to the astronauts, is a potential solution. However, re-entry into the Earth’s atmosphere remains a critical phase, potentially impacting the components of concern and invalidating the physical test evidence.
On the topic of autonomous operations, there are some reports that Boeing had not fully tested the part of the software that can provide autonomous control of the capsule as there was a requirement (for this expedition?) that there would always be a human onboard to fall back on. While the autonomous operations were demonstrated during its uncrewed orbital flight test in May 2022, it does not seem to be enabled during the current expedition. Replacing the software in orbit could take up to four weeks.
As the astronauts’ mission extends from 8 days to potentially two months or more, and possibly even eight months, we’re witnessing a 2,900% increase from their original (test) flight time. This extreme scenario underscores the potential challenges and risks involved in space missions. However, the project’s adaptability is a testament to the team’s ability to handle unexpected changes. While software project delays are uncommon, the stakes are significantly higher in space exploration. However, we can mitigate some of these delays by testing early and capturing precise requirements from the outset. When circumstances change, we inevitably analyse, replan, and continue to deliver the project.
To draw the line with rocket science further…. and into the Agile atmosphere. SpaceX is renowned for following a fast iteration approach where things get developed quickly, tested quickly, and designs adjusted quickly. This was done in the rocket manufacturing process, the rocket structure itself, and even to improve the rocket engines up to the actual launch vehicles. Leave your comments if you think the different approaches in development had different results.