Technical documentation
Find here the technical details of Q-Bot, along with what you need to install it, configure it and use it.
How Q-Bot works
Q-Bot is a self-contained nano-computer installed on your local network, with a built-in web interface.
The phone under test is connected to Q-Bot with a USB cable. Q-Bot drives it over ADB, the standard Android tool: every interaction runs directly on the device, inside the authentication app.
While tests run, Q-Bot works locally, with no dependency on an external service or an internet connection.
- 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 companion app triggers a Q-Bot scenario automatically when a 2FA notification lands on the phone.
It saves you from launching the scenario from your test suite.
Both modes can be used: triggering over HTTP, or automatic triggering through the companion app.
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
This section describes the security mechanisms currently built into the product, and the parts that belong to your own infrastructure and network environment.
- 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
A question, a doubt, an unexpected behaviour: write to the team. Technical support is included in the rental.
You can also write directly to contact@q-leap.eu. For anything that is not support, use the contact page.