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
- 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
- Long Term Maintainability
- 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
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Full archive