IoT Test Lab – New Release

On Friday 17th of November with Itecor, we have released for one of its customer (in a food and beverage industry) an IoT Test lab. It allows to run continuously automated test with IoT devices.

In the DevOps model, there are many new test challenges. One of these are to automate test with IoT devices without having a human to interact with the device. Everything is handled by custom controller for IoT Devices.

The architecture model used was the one described in one of the previous articles : IoT testing – Devices connected to a mobile.

With this lab, the customer will ensure that on each code commit of any application interacting with its IoT devices, it will be properly tested and validated without any regressions.

Itecor and us are proud of this new achievement and foreseen new opportunities in a near future in IoT Testing.

IoT testing – Devices connected to a mobile

In term of architecture there plenty ways to connect to an IoT devices, at least there are:

  • Devices connected to a mobile
  • Devices connected to a desktop or a laptop
  • Devices connected to a cloud solution

Today we will talk about IoT devices connected to a mobile. How these devices are connected?

Mainly they use Bluetooth. If they use Wifi, then they are using a cloud solution as proxy. That means we could categorize them as devices connected to a cloud solution. We will discuss how we could test them in a future article.

Before exploring how we could test them automatically, let gives a few solution examples of IoT devices connected to a mobile:

  1. Watch connected to a mobile (Apple Watch, FitBit, etc.)
  2. Beverage cooler and Freezer
  3. Coffee machine
  4. Construction tools
  5. Healthcare equipment

Last point before starting, here will cover the software part of the test. The hardware will be not covered in this article.


  1. The first challenge is how we get feedbacks from the IoT devices? Mainly the IoT devices have a very simplified interface with a very limited scope of functionality. But when we test, we need to access to a bit more of functionality, like to have access to details logs, have feedback on functional that return nothing, have a feedback when it changes state. Usually the hardware and firmware vendor of the device need to provide board that simulate the hardware but it uses the real firmware as it is a real device. In fact, what we test here is if the firmware is reacting properly as per the specification. And the firmware will interact with the board as it is a real hardware.
  2. When we talk about mobile phone device, we need to cover a huge number of devices version (hardware and OS). And sometime, the way the Bluetooth works, it could vary between different mobile phone type.
  3. There are no End to End solution for this type of architecture. You will need to take what already exists and you have developed, then put them together.

    Architecture and test

    Here is an example of architecture and which tools to automate test.

    To test this architecture, we could use a Java Test factory based on Appium, Selenium and Rest-Assured. This factory could be driven by a BDD (behavior-driven development) like Cucumber to define the test cases. The only missing part is the machine controller.

    As mentioned before the main challenge is to set a Hardware emulator to test the real firmware and have a full access to all input and output logs. This emulator will be handle by a custom developed machine controller. This controller will interface with the device through a serial port and the machine is expected to implement parsing the MCP messages.

    Regarding Appium, the setup is required to test a Native or Web application running in a Mobile device.

    To test the backend, let assume they are in majority accessible by Web interface or Rest Api. So, the best tool for that are Selenium for the web and Rest-Assured for the API.


    The major effort to set this kind of End 2 End test is to set the machine controller, and that could take more than 50% of the time required to setup this environment.  What is missing is a standard protocol to manage device through serial. And also, I’m quite sure any time soon this pain will be solved by any major Automated Test Framework leader (HP, Tosca) or by an open-source community. But in the meantime…good luck!

Related Article

Appium Desktop tutorial and setup

Appium Desktop tutorial and setup


Appium Desktop is a good way to understand the Appium mechanism. You will see how the elements are identified and what type of interaction you could accomplish. After that we could start industrialization with a test factory.

Today we are focusing on an iOS application. So we will use a iOS test application and it will require a Mac environment.

There is 2 main purposes to use Appium Desktop :

  1. Investigate how the application could be automated and identify the objects.
  2. Use as Appium server instead of using Node.js


We will setup Appium Desktop on a Mac (10.12)

  1. Install “Xcode” from “App store”. It is free.
  2. Run a first time Xcode and accept the License Agreement.
  3. Start the simulator : “Xcode” > “Open Developer Tool” > “Simulator”
  4. Check the version of your Simulator like below:

    iOS 10.3 simulator
    iOS 10.3 simulator
  5. Then go download and install the latest version of Appium Desktop ( like below:

    Download the latest version. Here it was 1.0.1 the latest version.
    Download the latest version. Here it was 1.0.1 the latest version.


  1. Start Appium and let the value by default like below:

    Appium starting screen
    Appium starting screen
  2. Start a new session :

    Appium logging screen
    Appium logging screen
  3. Create a new “Desired capability”. Ensure to report the right version of your iOS simulator!
         "platformName": "iOS",
         "platformVersion": "10.3",
         "deviceName": "iPhone Simulator",
         "app": "",
         "noReset": true
    Add in "Desired Capabilities" the required properties to run the simulator and define the application to test.
    Add in “Desired Capabilities” the required properties to run the simulator and define the application to test.

    Here we use a test application that allows you to practice and understand how to use Appium. (

  4. The Appium will show the screen of the iOS simulator (1), the inspector pan (2), the detail properties for a selected element (3). The (4) is the real simulator running on your machine, Appium is using a simulator to interact with your application. Appium is not providing its own simulator and this is a good approach, we could compare the simulator as the browser for Selenium.
    Appium Desktop (1) (2) (3) and iOS Simulator (4)
    Appium Desktop (1) (2) (3) and iOS Simulator (4)

    When you select an element in the (1) by double clicking, you will see in (2) the element name that has been selected and in (3) all the properties of the selected element. In this example you could “Send Keys”  or “Tap” in the selected field.

    How an element is defined and how you could interact with.
    How an element is defined and how you could interact with.


Now you can play with Appium and see how you could automate test with your App. It is a good way to see the challenge you could face when you try to automate your iOS, Android or WindowsPhone app.

Related Article

IoT testing – Devices connected to a mobile