All About Functional Testing of IoT Device Applications
- Business case for functional testing
- What does functional testing of IoT Device applications include
- Shortcomings of current approaches
Functional testing of IoT Device Applications can be a daunting task given the complexity and variety of “things”, applications, and scenarios that need to be tested. This article focuses on the need for functional testing, what it includes, and the shortcomings in the current approaches followed by the testing teams.
Business Case – why it is critical to do that?
Edge is becoming powerful – from being just data loggers in the past to hosting full-fledged powerful analytics applications. Functional testing for device applications is important to ensure that the application is behaving as expected for different scenarios arising out of the things and environments being monitored.
- Ensure the right computations – OEE, utilization, predicted failures
- Reduce high-impact consequences by generating on-time alerts and events
- Right visualization and reporting of the data
- Improve user adoption and utilization
- Reduce recalls and field visits for servicing through device management and remote fixes with functionalities like FOTA
- Ensure that the edge and cloud integration work fine beyond just the protocol and payload agreements to avoid last-minute surprises in the field tests or sometimes only on the field deployments
What does functional testing include in the context of IoT Edge Applications?
Functional testing in the context of IoT Edge Applications include testing for the data coming from things, environments, and other devices, commands coming from the cloud app, user actions spanning across the applications on the cloud and the device, device management triggers coming from the cloud applications and device-bound scenarios like connectivity, storage, temperature and time conditions.
Following are the applications that need to be validated
- Device management features including FOTA
- Data aggregation from other devices if applicable
- Data processing – real-time and batch
- Cloud communication including retries, store and forward, etc.,
- Command handling
What are possible shortcomings that one might have in the current approaches?
Testers need to test the data for happy and unhappy paths/scenarios that include data values:
- For one or more related parameters impacting the calculations
- For alert and event conditions
- Going beyond or below thresholds
- Getting missed or becoming junk
- Slowness in data read, write
- Commands coming from cloud applications
The testing needs to be executed for the communication characteristics arising out of network conditions, such as different upload, download bandwidth characteristics, network latencies, network connection errors, and MTU sizes leading to packet fragmentations.
Lastly, the testing includes, multiple devices being stacked together as a system of things if applicable and system-level behavior of the intelligent edge and cloud application for the different aspects of distributed systems like split-brain and so on.
However, testers use the following options today:
Considering that the edge applications are mostly non-intel, and are dependent on the peripherals for IO, the majority of the testing is done using the
- Physical devices in the bad with data coming from test equipment
- Physical devices fitted in the field test environments
These options are clearly not optimal considering the following issues
- Time is taken for testing
- Inability to generate a comprehensive set of test scenarios in action
- Repeatability and consistency
- Inability to test for network conditions
Doppelio – Purpose-built to test IoT applications
Doppelio’s patent-pending approach leverages the concepts of virtualization and simulation to give you a testbed that is a very close replica of the real world. Test scenarios are easy to create with Doppelio Web Application without having to write even a single line of code.
Rajesh K, Co-Founder & Head of Products