We’ve been doing application development and testing for a lot of years. Essentially, like many jobs, you can do it from the comfort of your laptop. But things change when you’re dealing with the Internet of Things.
We’re fortunate enough to be involved in a number of fascinating IoT projects including the testing component of them. And all we can say is, this is a very different proposition. With the Internet of Things, the “things” can be literally anything. They can be car components, medication, sports equipment, anything.
So how do you find a way of testing IoT that works equally well for cars, the human body and sports equipment? The simple answer is that you can’t. There is no one-size-fits-all solution for testing the Internet of Things. Be prepared for that.
What you need each time is a custom solution, a lab, which will provide, or simulate real-world conditions. That’s because, with straight software development, the inputs are software-based. But with the Internet of Things, the inputs are from hardware sensors, reacting to widely-varying stimuli from the outside world. And it’s those outside stimuli that change the game.
It means that you need to bring the real world into your lab to capture those outside stimuli. That’s why, at InfoStretch HQ, you will find, for example, a specialized sports lab where real balls are thrown at real bats. Try creating software that will simulate a real ball hitting a real bat. Sure, if you’ve got supercomputers from the future and unlimited resources, then go for it. Otherwise you will need a real bat, a real ball and a human to throw one at the other.
When the sensors pick up and transmit data, that’s where it starts to look like the testing world that you may be more familiar with. Then you’re back in the realm of testing software, test management software, test automation software and so on. If you’re lucky enough to be involved in IoT development or testing, the labs take you away from your desk and bring you into the real world. They enforce a change in your thinking. There is no way of escaping the real world and real-world inputs – which can only be a healthy thing in testing.