testology.io logotestology.io
← All case studies

Case study · IoT · Mobile, API and Alexa testing

Four years of test automation for a connected pool ecosystem

Fluidra's digital ecosystem connects pool equipment to a mobile app, cloud services on AWS and voice assistants, for pool owners and the professionals who look after their pools. testology joined the EMEA Digital & IoT QA team to build and run the automated testing across all of it, and stayed for four years.

Client
Fluidra, global manufacturer of pool and wellness equipment
Engagement
Embedded in the EMEA Digital & IoT QA team, four years
Focus
IoT device integration, Android and iOS apps, AWS-hosted APIs, Alexa voice assistant
Stack
TypeScript, Cucumber BDD, WebdriverIO and Appium, AWS, Jenkins, Xray and Jira

The challenge

The brief was to broaden automated coverage across the whole IoT ecosystem: APIs and services hosted on AWS, the Android and iOS apps, device integration, and third-party services such as in-app customer care. It asked for someone who would learn the nuts and bolts of the platform, propose new automated solutions, roll up their sleeves for end-to-end tests with real devices in the IoT Lab, and report risk to management in plain terms.

An ecosystem, not an app

A single user action, turning on a heat pump from the app, crosses a mobile client, an API on AWS, a device shadow in IoT Core and the firmware on the pump. Testing any one layer in isolation would have passed while the product failed.

Devices do not behave like web pages

Shadows update late, devices drop offline mid-test, firmware jobs take minutes, and a cloud phone is slower than the one in your pocket. Automation that ignores this produces flaky tests faster than it finds bugs.

What testology delivered

Five workstreams over four years, all in TypeScript and Cucumber, all running in the pipeline. The numbers below are counted from the mobile app, platform API, mobile API and device registration suites as they stand today.

4
years embedded in the QA team
3,800+
automated BDD scenarios across four suites
1,540
response-time assertions in the API suites
420
JSON Schema contract checks on API responses
20+
connected equipment models covered in the app

Mobile app automation

The iAquaLink pool app on iOS and Android, driven with WebdriverIO and Appium on Sauce Labs (Pixel and Galaxy families) and on real phones. Every connected model gets its own feature files: dashboard, schedules, settings, the Viewer variant for shared pools, and the alerts, down to checking that heat pump fault E04 arrives as a push notification and shows on the bell.

IoT device integration

Tests talk to the platform the way devices do: connect to AWS IoT Core over MQTT, write the reported shadow, and check what the app and API see. A device simulator generates shadow payloads from each product's JSON Schema, so most runs need no hardware. Disconnections, OTA firmware jobs with invalid files or wrong targets, and telemetry rules were all scripted. Occasionally it still meant a real heat pump in the IoT Lab.

Cloud API testing

Over a thousand Gherkin scenarios against the AWS-hosted APIs behind Cognito: accounts, pools, devices, schedulers, config files, WebSocket subscriptions and a small performance suite baselined against CloudWatch latency. Each scenario runs as consumer, viewer and administrator, including administrators impersonating users, because that is where permission bugs hide.

Alexa voice assistant

Setting up a pool with an Alexa-compatible device, retrieving the voice assistant configuration, and the boundaries around it: a viewer on a shared pool must not read the owner's Alexa configuration, and an administrator without the right identifiers must be refused. The scripted part provisions the user, device and shadows; the utterances themselves are then driven by hand from the Alexa Developer Console, which remains the most reliable way to check what a voice assistant actually says.

QA engineering and pipeline

One in-house TypeScript test framework shared by the app and API suites, so a step written once runs everywhere. Jenkins runs the API suites on ten parallel workers with a single-worker lane for the tests that cannot share a device, publishes Allure reports, runs SonarQube on the test code itself, and syncs feature files and results with Xray so Jira holds the same tests the pipeline runs.

Mobile app scenarios by area

2,374 scenarios in the app suite, excluding setup and teardown. Equipment dominates because every model carries its own dashboard, settings, alerts and Viewer scenarios.

Mobile app scenarios by areaHeat pumps & water care: 1621; Other equipment & lighting: 197; Account, pools & onboarding: 197; Localisation: 140; Robotic cleaners: 131Heat pumps & water care: 1621Heat pumps & water care1621Other equipment & lighting: 197Other equipment & lighting197Account, pools & onboarding: 197Account, pools & onboarding197Localisation: 140Localisation140Robotic cleaners: 131Robotic cleaners131060012001800

Platform API scenarios by area

1,038 scenarios in the API suite. Most run once per user type, so the effective coverage is several times the count.

Platform API scenarios by areaDevices: 269; Pools: 231; Device config files: 105; Pool schedulers: 91; Users: 75; Accounts: 48; Phones & push: 44; WebSocket: 25; OTA firmware jobs: 14; Alexa voice assistant: 11Devices: 269Devices269Pools: 231Pools231Device config files: 105Device config files105Pool schedulers: 91Pool schedulers91Users: 75Users75Accounts: 48Accounts48Phones & push: 44Phones & push44WebSocket: 25WebSocket25OTA firmware jobs: 14OTA firmware jobs14Alexa voice assistant: 11Alexa voice assistant110100200300

The approach

1

One framework, many suites

Instead of a separate toolkit per suite, a shared TypeScript framework holds the request builders, shadow helpers, configuration and reporting. New suites start from it; fixes land once.

2

Tests in the product's language

Cucumber scenarios read like the product spec: "Owner changes the pool temperature", "Viewer is not allowed to get the Alexa configuration". Designers and product owners can review coverage without reading code.

3

Design for hardware latency

A device shadow does not update instantly and a phone on Sauce Labs is not a laptop. Every test user and device carries the run and worker id in its name so parallel runs never collide. Only the 23 scenarios tagged as genuinely latency-sensitive are allowed to retry; the rest fail hard, so a slow device never hides a real bug.

4

Run everywhere, every day

The suites run in the pipeline across development, test and staging environments, on both mobile platforms, and every run pushes its results to Xray, so a release candidate already has its test evidence in Jira when the release meeting starts.

The outcome

Four years of automation did not remove the need for a person in the IoT Lab with a phone in one hand and a heat pump remote in the other; some failures only show up with real water and real firmware. What it did was make that person's time count, because the thousands of checks that can be scripted already ran overnight, on both platforms, against every environment.

Great collaboration with [testology], very skilled and very committed. They deserve 6 stars!
Vicenç Luna, Fluidra. Lightly edited to remove an individual engineer's name.

Regression at ecosystem scale

Thousands of scenarios cover the app, the APIs and the device layer together, so a backend change that would break a heat pump screen is caught before the app build, not after the app store review.

Coverage that grows with the catalogue

Each new connected model, from heat pumps and chlorinators to robotic cleaners and smart plugs, lands with its own feature files, alert scenarios and Viewer variant. The pattern is established; adding a product is routine.

Evidence where the business looks

Test cases live in Xray, results land in Jira, reports are in Allure, and the pipeline decides when a suite runs. Upper management sees progress and risk without asking QA for a summary.

Shipping hardware with an app attached?

We test the device, the cloud and the phone as one system, in the language your product team already speaks. We find it before your users do.