Smart home testing
In smart homes, mobile apps are the central hub for controlling devices and services. QiTASC’s end-to-end automation framework simulates real user interactions and ensures that updates or code changes don’t disrupt the seamless functionality of the entire smart home ecosystem.
Why smart home testing
Smart home testing ensures that smart home products remain reliable, stable, and deliver a consistently high-quality user experience.
Smart home systems continuously evolve, adding new features and updates. Testing for quality assurance expects to test every device that interacts with the system through mobile apps or other graphical interfaces. It should detect bugs and ensure existing features for them to continue to work seamlessly.
Remotely accessible real IoT devices
The QiTASC test automation framework replicates tests the interaction between graphical interfaces and the real device IoT setup within the remote lab.
This way, we create automated scenarios like verifying that windows are closed, doors are locked, or appliances respond correctly to app commands.
All interactions through the app or interface can be fully automated and verified. This approach ensures your smart home products remain reliable, stable, and deliver a consistently high-quality user experience.
How it works
Smart home devices can be verified quickly and reliably by automated tests.
The technology behind
QiTASC offers a remote lab that enables you to develop and execute your test cases from anywhere. For the IoT industry, we have developed an IoT setup, specialized in smart home testing.
Use cases
Onboarding of smart devices (Smart bulb, smart meter, smoke detector, etc.)
Network integration and network outages
Multiple devices operate together
App-device commands
Security, locks, and permissions
Sensor and usage data
Firmware and software updates
Alerts and push notifications
Video: IoT setup in the remote lab
We have developed a setup for remote acceptance testing of IoT devices. You can control all of them remotely from home.
You are currently viewing a placeholder content from YouTube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationTranscript
Remote lab: IoT setup
Acceptance Test Environment for IoT Tests
This is our test acceptance environment for the IoT testing.
Here we have several devices which are connected to hardware which is developed by us. We have four different devices.
Here we have a smoke detector. On the back you see the hardware which we have developed.
We have a microphone which is installed here. This part is also connected to the servo motor which can press some buttons on the smoke detector.
And what we also do is we have real oil inside and we burn it. We generate temperature here which burns real oil and this goes into the detector and an alarm is generated immediately.
On top we have a fan. With this fan we take the smoke out and then we expect that the alarm vanishes. We can trigger all the conditions which are necessary in order to handle these devices.
Here we generate smoke. We detect, we have a microphone inside, we record the signal strength, and everything is then automatically controlled by our test infrastructure.
On the bulb here, we have an RGB-sensor connected to this, so we can measure the colour of this bulb. Automatically, it changes. We can trigger it from our test infrastructure. So we change the colour, we measure it, and then we compare the measurement if it really fits to what had happened here.
Here we have movement detection. We generate with this bulb some infrared signals and with the servo motor we can move it.
And here is the detector. If it detects motion in combination with heat, it also generates an alarm. And here we have a magnetic sensor which acts on a window. If the window is opened, the magnetic contact is broken and then it generates an alarm.
We can trigger all these events independently. And you also see here the place for the battery. This is also one of ours.
With this thing we can control the current in the battery. If we have a low battery status – or we can trigger it as if it has a low battery status – then these sensors have also some specific tones. There is also a microphone integrated here in the bottom. We measure then the low battery signal. We can create any use case a customer normally has with these devices.
We can generate and emulate it with our environment.
Interested in more? Visit us online!
Tutorial video: IoT test case
A testing expert walks you through executing an IoT test case using a door-window contact sensor. He demonstrates this with intaQt studio, running the test on our remote IoT setup.
You are currently viewing a placeholder content from YouTube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationTranscript
IoT test case with intaQt studio
Hello, my name is Bernhard from the electronics department of Qitasc. Today I would like to present an IoT project with an IoT test case.
The system we are testing consists of a system that is installed at home, a smart hub from the company Samsung in this case, and a door-window-contact as example. We can also use other devices, but in this case I would like to demonstrate a test case with a door-window contact. And a mobile phone.
We want to test the behaviour that you have at home. You have attached the door-window-contact to a window and want to receive a notification on your mobile phone as soon as someone opens the window.
Now we want to test both ends automatically. We do this by not mounting the door-window-contact on a window, because how do you open a window automatically?
We have mounted the door-window contact on a device that has a servo motor attached to it and this servo motor can open the window, so to speak. It folds the door-window-contact away from the magnet. Here is the magnet, here is the door-window contact. This part can be folded away and closed again.
The door-window-contact is connected to the Samsung smart hub via the Zigbee radio protocol and the Samsung smart hub is connected to a backend server at Samsung via the internet.
The phone, on which an app is installed, is also connected to the backend server at Samsung and via this connection, the connection to home is established. When the sensor detects that the window is opened, the information is transmitted to the backend server at Samsung. The phone is then notified that the window has been opened and is supposed to display this on the app.
That’s what we want to test. In order to do this, we have this servo motor. This servo motor is controlled by our electronics.
This is the board with the electronics. Of course, it can do much more than just control the servo motor; all the functions are also integrated. It is important to know that there is a Raspberry Pi in the background. This Raspberry Pi is also connected to the network and can be controlled by us. It then controls the functions on this board. I can connect four devices to this board.
In this case, only the first device is connected, here this door-window-contact. Via this platform that I have here, I can not only control a servo motor, I can also control many other functions.
For example, I can also simulate the battery here. So, there is no battery inserted in this sensor, but a battery dummy is inserted. This battery dummy is supplied by this circuit board.
With it I can also test, for example, the case when the battery becomes empty, that the device tells me that I have to replace the battery. I can also use it to switch relays and perform many other functions, adapted to the application, which is needed for the automation of a smart home.
The test case is processed via the intaQt studio as usual, which is our platform. Various steps are carried out in this test case, which are formulated almost naturally in terms of language.
We start by wanting to get the phone: Give my phone as A. Here even the serial number is given. That means I get a phone that has to be connected to my machine with this serial number.
And insert a full battery into the device multipurpose sensor demo. The device here, this door-window-contact is a multipurpose sensor. It can do more than just door-window-contact, that’s why it’s called a multipurpose sensor. And I put a full battery into that.
Then I open the app on the phone. And close the window monitored by the sensor MultiPurposeSensor_Demo. I make sure that the servo motor brings the door-window-contact into the initial position “closed window”.
Then on A – That’s the phone, we got it and called it A. Then on A, select the device MultiPurposeSensor_Demo from the devices menue. So on the phone the app is opened and in the menu of this app we go to the sensor we want to look at.
And on A, assert that the contact sensor of the MultiPurposeSensor_Demo says “Closed”.
We have previously set the sensor to the initial position “closed window” and now also want the app to indicate that the window is closed as an initial condition. And then the actual test begins.
Then open the window monitored by the sensor MultiPurposeSensor_Demo. This means that with this command, the servo will swing the sensor away from the magnet. This will look to the system as if the window is open.
Then we give the system three seconds to wait. And wait for 3 second, so that there is really enough time for the sensor to notice this and for it to be transmitted. That’s often a problem with automated test cases, that you don’t expect the machine to be that fast. Much faster than you would be as a human being.
So the automat can do that almost simultaneously, but that would go wrong. So you have to give the sensor the opportunity to react, to transmit it all, to play through to the backend server at Samsung and then down to the phone. And that’s why there’s a three-second pause It’s also easier for us to observe what’s happening that way, because it’s slower.
And on A, assert that the contact sensor on the MultiPurposeSensor_Demo says “Open”. That means we want to see after three seconds that the app shows that it is open.
And again we wait for three seconds: And wait for 3 seconds. Then close the window monitored. That means we shut down the sensor again. This time we even wait for six seconds and then we see that the app again shows that the sensor reports closed.
I will now start the test case:
The phone is now received from our test machine. The test case name is already displayed. Then the app is started. The sensor is navigated to in the app. And then it is verified whether the initial condition is correct. It said “Closed”. It opened, now it says “Open”. After a waiting period, it then moves back to “Closed” and we also want to see that it says “Closed” again.
This is the case. Test case is green and has the state “Passed”. So it worked.
We want to look at what would happen if the test case went wrong. Would we notice that?
I will start the test case again and then I will intervene so that the window cannot be closed. The sensor will continue to report “Open” even though the window is supposed to close.
Now it has moved to the initial position “Closed”. It is navigated to the sensor. The sensor must show “Closed” as initial condition. That is the case, it is “Closed”. Now it is opened.
Now I hold my finger inbetween and make sure that the servo motor can no longer move the sensor back to the “Closed” position. This means that it continues to display “Open” even though it has actually closed the window, and that is an error.
And this error has also occurred here and has been detected, in this case: on A, assert that the contact sensor of the MultiPurposeSensor_Demo says “Closed”. But it still showed open. It is an error. It has been detected by our machine and displayed accordingly.
Interested in more? Visit us online! www.qitasc.com
Release reliable smart home services
Get to know the possibilites of IoT testing for your service and experience the QiTASC approach in a live demo.
