Software testing in space

They say the best fiction is founded in reality, so here’s an idea for a dystopian science fiction blockbuster: a satellite hits a piece of space debris and is knocked out of its carefully defined orbit around the Earth. This satellite hits a neighbour and it, another. Suddenly, a cascading wave of collisions begins to roll, rumble and finally rage. As it does, Earth begins to lose banking, telephony, GPS, internet access — and finally, the lights go out...

The idea isn’t so far fetched, says Beth Clarke MBCS, a committee member for the BCS SIGiST (Software Testing Special Interest Group) and a PhD student at the University of Strathclyde. Indeed, her PhD project explores how distributed ledger technologies, such as blockchain, may help stave off the above nightmare — a not-so-hypothetical scenario with a delightfully Star-Trek-original series name: Kessler Syndrome (to be written in red poster-sized, spikey text). Movie fans will, of course, recognise the Kessler Syndrome as a central player in the 2013 film Gravity.

Beth says space is getting busier all the time. Starlink, the satellite internet constellation, consists of over 6,000 small, mass produced satellites, each in a low Earth orbit. All of this makes space an ever more dangerous environment in which to work and potentially live.

Navigating around space junk

‘Right now, there’s no way to autonomously protect satellites from colliding with each other and with space junk’, she says. ‘Satellites can’t independently communicate with each other to share information and automatically perform orbital manoeuvres to move out of danger’s way. Any current process is centralised, requires a lot of people on Earth, and isn’t speedy or reactive.’

Beth explains that the problem will only worsen, particularly when space tourism finally becomes a reality. When more people are in space, the pressure to ensure their safety will be even greater.

‘My research is looking at how we can use distributed ledger technologies to augment the orbital manoeuvre processes’, she says. ‘We’d ideally have all the satellites’ sensor data about their locations stored in a distributed system that everyone can access. We can then potentially use smart contract technology to enable satellites to coordinate and move out of each other’s way.’

Along with making space safer, preventing satellites from having orbital collisions also boosts the space industry’s sustainability credentials. Building and launching satellites can be an incredibly resource intensive business. She says that having the result of all these endeavours be burned up in the Earth’s atmosphere would be a terrible waste. As such, a clear and indelible line links safety in space and enhancing sustainability.

A lucky apprenticeship

‘So, I did my undergraduate degree in astrophysics at the University of Bath’, Beth says, explaining her career. ‘In my final year, I studied a unit called computational astrophysics, and that’s where I learned to code — I did a bit of C and a bit of Python…modelling the motion of comets and photons…it was so cool! I wanted to do this full time.’

After graduation, she found it difficult to find her dream job in the tech sector but eventually began a BCS accredited graduate apprenticeship. The programme focused on software engineering. Over the next five years, she moved into software testing and then into DevOps.

‘As a PhD student, my study days now are quite different from my working days’, she says. ‘Today, I’m focused on reading research and writing technical pieces. But, as a software tester, there’d be lots of team meetings — making sure everybody on the project is aligned. From there, a lot of my day involves programming…writing test cases, looking at regression test results and updating our test harness which was written in Python.’

Beth’s passion for software testing started, she claims, quite accidentally. Her first graduate role was simply as a tester — it was the first role that came along. ‘But, it suited my skill set’, she says. ‘Coming from a physics background I’m somebody who likes to do experiments and test things out. You can give things a go, and failure is accepted — you don’t expect all your tests to work the first time…I found a love for testing.’

Continuing, she says: ‘It’s such a fun career, but it wasn’t a pathway I was told about. Software development and software engineering are terms I’d heard at university, but I'd never heard of software testing. It’s a fun career, and I want to tell everyone about it!’

Safety critical software

One of the first projects she worked on saw her testing software that enabled emergency brakes on trains. If the train went too fast, the software would take over and slow the train down safely. 

Beth’s background and experience in testing software for critical systems leads to the potentially revealing question: how does she feel when she’s forced to entrust her safety to software? Would she be happy giving control to a driverless car and its unseen swathes of safety critical code?

‘Most people have no idea they’re trusting software in these situations’, she says. ‘Possibly that’s a good thing — it shows the software is doing its job and getting you safely from A to B.’

Laughing, she says: ‘But I’ve seen behind the curtain! I know what’s going on, and I know the risks. So, for somebody with my background — it’d be normal to be a bit nervous. That said, knowing how thorough processes are and how high the standards are...and remember; ultimately, it’s not about trusting the software, it's about trusting the people and the processes behind it — trusting that they have written and tested the software. With all my heart, I trust every piece of software I’ve developed and every piece my friends and colleagues have developed.’

The tester’s mindset

The key to being a good tester, Beth believes, isn’t entirely about a predisposition for maths and physics. Instead, she says that good testers need to be creative — they need to be able to think outside the box and come up with new and novel scenarios. This is particularly important when working on new and complex systems where there might not be an existing body of prior work and experience.

‘Testers don’t add their value in repetitive work’, she says. ‘It’s not all about running automated tests where you have a pipeline that checks your code. That’s a tool to support testing. The real value is in activities like explorative testing where you’re playing and seeing what happens. That requires some creative flair and a lot of curiosity — you have to want to understand what the software is capable of. You need the drive to understand system context.’

Software’s hard life in space

When it comes to the context in which software functions, there’s probably nothing more challenging than working in space. For starters, Beth explains that radiation is a big problem. On Earth, we’re protected by the atmosphere and our magnetic field. Systems can suffer if the hardware upon which the software is intended to run isn’t designed with this in mind. It’s not unheard of, Beth says, for bits to be flipped and circuits fried when struck by particles.

‘Space is such an extreme environment’, she says. ‘We also have temperature issues — space is very cold but, to make things worse, in some places, it is very hot, and the change between those temperatures can be dramatic. The increase in temperature gradient from the sunny side of the Moon to the dark side is very steep. Can your hardware cope with these huge and rapid changes in temperature? Will it crack, will it expand?’

Software and systems deployed in space must also function reliably and safely when faced with limited power supplies. Spacecraft generally rely on solar power, so they must be designed to be frugal and conserve energy. The distance from Earth also means communications with home can be limited. This means updating software will be hard, and data transmissions may have to prioritise only essential information. Along with limited bandwidth, communication links may be delayed or sporadic if a satellite orbits the Moon.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

‘One of the challenges I’m facing in my research is: how do I keep all the satellites in a network communicating even if somebody dips out of the [community] into a silent zone?’, she says.

A satellite's potential lifespan is another factor that needs to be considered and built into test scenarios. Satellites can be expected to function, in some cases, for decades. ‘The International Space Station is expected to last for 30 years’, she says. ‘So, we have to consider how the satellite will be sustained. We can’t easily send somebody up there to fix it.’

In some cases, Beth explains, hardware engineers do such a good job that a satellite might still be functional, but the technology on board may be outdated and superseded, requiring an update to continue to be useful. She gives an example of a weather observation satellite where, depending on its age, the camera resolution may no longer be fit for purpose even though the satellite is still capable of taking images.

‘De-orbiting that satellite would be a huge waste of resources’, Beth says. ‘So, the question is: how can we use software to extend the satellite’s lifespan? Could we send a software patch to it that repurposes it? This would be much more sustainable — we don’t want to spend more money and time and take up more space. Why not keep the satellite up there? Software can play a huge part in that. So when we’re testing, we think about that — can we swap it out to do something new?’

Finishing this point, Beth says: ‘I’ll be presenting a paper on this. It’s about the smart maintenance of satellites…looking at a satellite’s health status, monitoring it using machine learning and predicting how long it has left in its lifetime and what its quality of service could be. We can use that information to work out if there’s a better purpose for it.’

The importance of diversity

Finally, we discuss diversity and why it is critically important for test teams to be staffed by people from as many backgrounds and communities as possible. Moving from the drama of the Kessler Syndrome, Beth introduces the Pesticide Paradox.

‘If everybody on the test team is the same, you’ll bring far less value to the product’, she says. ‘The Pesticide Paradox is where, if you repeat the same tests over and over again, you don’t find any new defects. It’s how the bugs become resistant if you use the same pesticide on a field repeatedly. In software testing, that doesn’t mean that your code is defect free — it just means that the tests you’re writing aren’t finding anything new.’

She says the ideal team will consist of people who bring different perspectives, experiences, cognitive processes and cultural backgrounds.

‘Without diversity, there will be no innovation, invention or curiosity…none of that creativity, which then feeds through to bugs being missed. Diversity is really important, particularly in safety critical systems.’

‘I also mean diverse in terms of experience too. Don’t just have your most senior testers working on your most complex projects…get the juniors in! Get the apprentices involved from day one. I was fortunate as an apprentice to be brought into the fold really early on. I brought a fresh pair of eyes and spotted things other people didn’t see because they’d been in the same pattern for years.’