Codethink works on many projects where testing is a bottleneck in the development process. Our dream is to enable automated hardware testing for all our clients, and we're releasing a new open source tool named Q.A.D. that brings this a step closer.
Introducing Q.A.D.
Q.A.D. (Quality Assurance Daemon) provides remote interaction with a device in place of having to physically interact with it. It's a remote control for your test rig.
In effect, it's a daemon that provides a REST API. You can trigger simulated input events via HTTP requests, and you can also fetch screenshots of any display the host device is connected to.
This both eliminates the need to physically interact with hardware and allows tests to be completely automated.
Q.A.D. is a free software tool licensed under the MIT licence. It has minimal dependencies, and can be compiled into a single binary that will use libraries already existing on your device. When running, Q.A.D. is as light-weight as possible to avoid slowing down tests.
Why we developed Q.A.D.
We like openQA a lot. openQA simulates user interactions using emulated keyboard, mouse and touch input devices, and captures display output using the VNC screensharing protocol. We've also used openQA with LAVA, which works nicely for running desktop Linux on development boards, using the VNC screensharing protocol to simulate input events and capture display output.
For our customers in the automotive and embedded Linux spaces, it's not practical to use VNC. We want everyone to enjoy the benefits of openQA, and our answer to that is Q.A.D.
Q.A.D. Architecture
The above picture shows Q.A.D. architecture at version 0.0.3
. In short, Q.A.D. receives requests from a caller and then simulates human input via its input backend, or takes a screenshot via its screen backend and send it back.
For further architecture details, please refer to Q.A.D. documentation.
How to use Q.A.D.
As mentioned previously, Q.A.D. is interacted with via HTTP POST requests, or a GET request in the case of screenshotting. These requests are directed at end points and have their parameters described in JSON. The currently supported endpoints are: /screen
, /touch
, /swipe
, and /button
.
Here we only show one example to avoid a lengthy post, but you can always read more about this on Q.A.D. documentation.
/touch
curl -X POST -d '{"x": <int>, "y": <int>, "duration": <int>, "event": <int>}' http://<rig-ip>:<port>/touch
The touch endpoint lets you touch the screen at any given position. You can also specify the duration of how long you want to touch the screen, this lets you mimic long presses. There is then also the event
parameter, this lets you specify the input device; useful when you have a mouse and touchscreen connected.
Q.A.D. and openQA
One great use case for Q.A.D. is having it work in tandem with openQA. openQA lets you automate testing, primarily in emulation. Combining it with Q.A.D., you can automate testing on actual hardware. You can automate the testing of the entire boot process of a system on physical hardware, without even being in the same country.
To allow openQA to talk to Q.A.D., there have been a few additions made to the arguments you can pass when starting an openQA test.
QAD_SERVER_ADDRESS=http://<qad-device-ip:qad_port>
QAD_SCREEN=<screen-number>
XRES=<screen-x-resolution>
YRES=<screen-y-resolution>
QAD_TOUCH_DEVICE_NO=<touch-input-device-number>
Setting these parameters appropriately will let you continue to use openQA just as you normally would.
You can get further detail about this in our Q.A.D. documentation.
Conclusion
We developed a new tool for end-user blackbox testing: Q.A.D. The tool is lightweight and makes test engineers' lives easier by allowing remote interaction with hardware via local network access, which is particularly useful for automotive/embedded device companies.
Although we have done our best to make Q.A.D. as easy-to-use as possible, integrating it into your company's unique purpose or process could still require work. Codethink has a lot of talented engineers, and we are happy to help you. Please contact us at sales@codethink.co.uk if you are interested.
Other Content
- Codethink/Arm White Paper: Arm STLs at Runtime on Linux
- Speed Up Embedded Software Testing with QEMU
- Open Source Summit Europe (OSSEU) 2024
- Watch: Real-time Scheduling Fault Simulation
- Improving systemd’s integration testing infrastructure (part 2)
- Meet the Team: Laurence Urhegyi
- A new way to develop on Linux - Part II
- Shaping the future of GNOME: GUADEC 2024
- Developing a cryptographically secure bootloader for RISC-V in Rust
- Meet the Team: Philip Martin
- Improving systemd’s integration testing infrastructure (part 1)
- A new way to develop on Linux
- RISC-V Summit Europe 2024
- Safety Frontier: A Retrospective on ELISA
- Codethink sponsors Outreachy
- The Linux kernel is a CNA - so what?
- GNOME OS + systemd-sysupdate
- Codethink has achieved ISO 9001:2015 accreditation
- Outreachy internship: Improving end-to-end testing for GNOME
- Lessons learnt from building a distributed system in Rust
- FOSDEM 2024
- QAnvas and QAD: Streamlining UI Testing for Embedded Systems
- Outreachy: Supporting the open source community through mentorship programmes
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part one of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: Exploring a Bug in Stack Unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Achieving Long-Term Maintainability with Open Source
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Full archive