As the IoT market is exploding and giving us many new kinds of devices to test, software testing is more important than ever. It needs to be easier, cost less and happen faster to support this rapidly growing market. At the forefront of simplifying and improving software testing is service virtualization.
My career in service virtualization started long ago, and I was on the original team that brought the first service virtualization product to the market, iTKO, now CA Service Virtualization. It was a fun experience and my first successful startup. I learned many things personally, and many more things technically. The three main technical points I took away from service virtualization that apply to device virtualization are:
1. Software is easier
You can control software better than you can hardware. Do you have a product that you want to make sure can do x, y, and z but not Q? Only capture the interactions of x, y, and z. Write a negative test case for Q.
You don’t have to connect anything or run wires anywhere. You don’t have to worry about breaking hardware. With hardware, there are safety and cost considerations. You might not be able to replace what you break, and you may not have enough of them.
If you have a virtual service or device, you don’t have to worry about breaking anything and you can have as many as you want. That makes software in IoT much more versatile. You don’t have to deal with heterogeneous IoT devices, platforms and setup costs.
2. Software is free (ish)
It’s cheap. Even in a traditional software environment, testing against 300,000 servers is prohibitively expensive. With software as a service or device, you pay for the basic license, but you aren’t paying for people to build it, you don’t have to heat or cool it, store it, or run cables to it. Any kind of testing at scale must be done with software and it’s great to have a cheap and easy way to make sure that your code works against whatever you want to put it on.
With good machine learning, you can learn the device transactions of a couple of devices and scale it up to as many devices as necessary. By creating adaptive virtual devices, you can now have good data to test against, mimicking thousands of real devices without having to build, purchase, maintain, or store thousands of IoT devices.
3) Software can be dumb, in a good way
Adaptive virtual devices can be hardware and protocol agnostic. It doesn’t really matter what interactions you want to observe or where you want to observe them. The software doesn’t care, because at the end of the day it’s all network transactions.
Because we interact at the protocol layer, if the protocol of your device is useful to you, we can help you model it effectively without having to rely entirely on field testing or randomly generated data sets. Machine learning can serve as a translator between your code and your device, leaving you with the fun work.
Adapting the concepts of service virtualization for IoT means that developers can test their code against realistic data scenarios and at scale before the device itself is ready for testing, allowing them to develop more quickly with less risk. Software is more cost effective, less particular (more protocol agnostic), and much easier to incorporate into code than hardware.