Technical documentation
How to install Q-Bot on your network, connect a phone, build a scenario and trigger it from your test suite. This page is for whoever actually integrates Q-Bot; to find out what it does and whether it fits your environment, see the technical specifications.
How Q-Bot is built
A complete computer sitting on your local network, an Android phone connected over USB, and a web interface served by the device itself.
The device is a small computer that runs on its own, on the network where you install it. It calls no external service while tests run, and needs no internet connection to run them.
The phone under test is connected to it with a USB cable. Q-Bot drives it over ADB, the standard Android tool: every tap lands on the physical screen, inside the genuine authentication app.
- Your test suite calls Q-Bot over HTTP
- Q-Bot replays the scenario on the phone, over ADB
- The second factor is approved in the real app
- Your test carries on
Installation and network
The device arrives ready. What matters is where you plug it in and what it expects from your network.
Put the device on the same network as the machine that runs your tests: that network, and only that network, is what gives access to the interface and the API.
Connecting the phone
A physical Android phone, connected over USB, driven by ADB. No emulator, no simulator, no stub app.
One device drives one phone at a time, and requests are handled one after another, in the order they arrive.
Building scenarios
A scenario is built on screen, on a screenshot of the app under test. There is no scripting language to learn.
- A screenshot of the app is the background of each step
- Tap points are placed with a click, and numbered
- Waits are set to the millisecond
- Steps can be reordered
- Scenarios are versioned on the device
- Screenshots stay stored locally
Each scenario carries a numeric id: that is what your test suite will call.
The REST API
Three endpoints, over HTTP, on the local network. No SDK, no proprietary plugin, no agent to install in your continuous integration.
- Self-hosted: everything stays on your local network
- Works with any test suite that can make an HTTP call
- The API expects no key: access control is your network's
Triggering from your test suite
The same HTTP call, in five tools. Open the one you need.
# Trigger the 2FA scenario
import requests
requests.get(
"http://q-bot.local:8000"
"/scenarios/42/execute"
)
# The test carries on
driver.find_element(
By.ID, "dashboard"
).is_displayed()// Trigger the 2FA scenario
cy.request(
'GET',
'http://q-bot.local:8000'
+ '/scenarios/42/execute'
)
.its('status')
.should('eq', 200)
cy.get('#dashboard')
.should('be.visible')# Trigger the 2FA scenario
curl -s \
http://q-bot.local:8000 \
/scenarios/42/execute
# LuxTrust OTP
OTP=$(curl -s \
http://q-bot.local:8000 \
/get-luxtrust-otp \
| jq -r '.otp')*** Settings ***
Library RequestsLibrary
*** Test Cases ***
2FA Login
# trigger the scenario
${r}= GET
... ${QBOT}/scenarios/42/execute
Status Should Be 200 ${r}// trigger the 2FA scenario
given()
.baseUri("http://q-bot.local:8000")
.when()
.get("/scenarios/42/execute")
.then()
.statusCode(200);
// the test carries on
assertTrue(
dashboard.isDisplayed()
);The companion app
The second way to trigger a run: the app is installed on the phone under test and starts on its own as soon as a 2FA notification arrives.
Installed on the phone under test, it watches the notifications of the authentication apps and triggers the matching scenario as soon as one arrives. No call from your test suite is needed.
Both trigger paths live side by side in the same environment: the HTTP call when your test decides, the companion app when the app under test asks for the second factor.
The QR code on the device screen
The device has a small built-in screen. POST /display-image shows a QR code on it for the phone to scan.
Some authentication flows ask you to scan an image rather than type a code. The device screen then acts as the display: your test sends the image, the phone scans it, the flow carries on.
Data storage
Scenarios and their screenshots stay on the device. Nothing is sent to an external service.
Q-Bot is built for test data. The accounts used in your scenarios should be test accounts.
Security
What the product guarantees today, and what it leaves to your infrastructure. Stated as it stands, with no promise beyond.
- Self-hosted: the device lives on your network, not in a cloud
- No call to an external service while tests run
- No internet connection is needed to run a scenario
- Scenarios and screenshots do not leave the device
The API expects no authentication key. Access control is therefore your network's: put the device on a segment whose access is already controlled, as you would for any test equipment. For any compliance question specific to your environment, write to us.
Support and replacement
What the rental includes, and what happens if the device fails.