Senior QA Engineer

Senior QA Engineer (Connected Device Fleet & Cloud Platform)

Type: Full-time, remote (strong overlap with US Central / AU business hours) Level: Senior

About the role

We build and operate a large-scale platform for connected devices deployed across thousands of locations, plus the cloud services and web applications that drive them. It is a full-stack, high-scale environment: a runtime that has to work reliably on constrained hardware in the field, a cloud backend that publishes data to the fleet and ingests telemetry at scale, operator-facing web apps, and a mix of modern and legacy code.

We are looking for a senior QA engineer who owns quality across that whole surface: on-device runtime, cloud services, and UIs. Two truths shape the role. The first is that what a device reports is not always what is true. The second is that the artifact that ships is not always the one you test against. A senior here designs the strategy that closes both gaps and automates it, rather than running test cases by hand.

What you will own

•         Test strategy across the on-device runtime, the cloud services, and the operator UIs: risk-based, automated, and wired into CI.

•         End-to-end automation of device and cloud flows, plus on-hardware validation where behavior only appears on real devices.

•         API and contract testing of the services and the schemas that flow between device and cloud.

•         Load and performance testing of the telemetry ingest and the service tier, run against staging so you never affect production.

•         Regression on the highest-risk surfaces, and release readiness validation with rollback checks.

•         CI quality gates that test by behavior (install the package, run the command) rather than by a file existing.

•         Raising the automated-coverage floor where it is thin, including areas that are hard to test today.

Required (must-have)

Non-negotiable for day-one productivity.

•         A test-strategy and automation mindset: you design coverage by risk, automate it, and integrate it into CI. You are not a manual case-runner.

•         Jest and authoring tests in TypeScript / Node.js, testing pure logic directly and mocking at boundaries.

•         API and contract testing (Postman / newman or equivalent) and schema validation: JSON contracts (JSON:API or similar), JWT / JWKS, and response/report schemas.

•         Coverage tooling (nyc / istanbul) and the judgment to read a coverage report critically.

•         Hand-written SQL to assert data state (MySQL 8), and Bash for on-device and CI checks.

•         CI quality gates in GitLab CI.

•         Enough distributed-systems and AWS literacy to test them: idempotency, eventual consistency, retries, ordering, and what "eventually" means for an assertion.

•         The core QA judgment: separate "reported" from "true", think in contracts and schemas, and account for the shipped-artifact-vs-tested-artifact gap.

Nice to have, or the strength we accept instead

We would rather hire the aptitude than the exact tool. If you do not have the ideal item, the accepted equivalent is what we look for instead, and it is what we will probe in the interview.

• Ideal experience: Legacy browser e2e: Karma + Protractor (AngularJS) x Accepted equivalent (the transferable signal): Any modern browser e2e (Playwright, Cypress, WebdriverIO, Selenium) plus willingness to test a legacy frontend
• Ideal experience: Mocha + Chai + Sinon + nyc x Accepted equivalent: Any xUnit-style framework plus mocking plus coverage tooling, and how you read a coverage report
• Ideal experience: Artillery (load) x Accepted equivalent: Any load/perf tool (k6, JMeter, Gatling, Locust) with percentile and saturation reasoning, not a single req/s number
• Ideal experience: Postman / newman x Accepted equivalent: Any API/contract testing (supertest, REST-assured, Pact, or consumer-driven contracts)
• Ideal experience: Docker + containerized test environments x Accepted equivalent: Any ephemeral or reproducible test-environment orchestration
• Ideal experience: On-device / hardware-in-the-loop testing x Accepted equivalent: Any embedded, device, or IoT QA, or testing where physical and logical state can diverge
• Ideal experience: Security / authorization testing x Accepted equivalent: Any experience validating authz, RBAC, permissions, or policy, and thinking like an attacker at a boundary
• Ideal experience: Chaos / failover / fault injection x Accepted equivalent: Any resilience testing, or reasoning about split-brain, leader election, and partial failure
• Ideal experience: Media / visual regression (ffmpeg) x Accepted equivalent: Any pixel or visual-diff testing, or reasoning about verifying a rendered output
• Ideal experience: New Relic / observability x Accepted equivalent: Any APM (Datadog, OpenTelemetry, Grafana); asserting on metrics and traces, not only on responses
• Ideal experience: Python x Accepted equivalent: Any scripting language for test tooling and fixtures
  

What we look for in a senior QA

•         Designs a test strategy and automates it in CI, rather than running cases by hand.

•         Prioritizes by risk, and can say what not to test and why.

•         Separates "what the system reports" from "what is actually true," and asks for the data.

•         Thinks in contracts and schemas, and in the artifact that ships versus the one under test.

•         Reasons about scale with percentiles and saturation, and about failure with fault injection.

•         Uses a reference implementation as the specification when proving behavior.

Problems you will help us solve

•         Proving a device is genuinely working, not just reporting that it is, and catching the stale-heartbeat case that looks fine on a dashboard.

•         Proving the system shows the right thing at the right time, and building the fixtures and oracle that make that repeatable.

•         Load-testing the telemetry ingest and the services at fleet scale, with realistic arrival patterns, without ever touching production.

•         Working out what a simulator can prove and what only real hardware can, and covering both.

•         Catching the case where the thing you tested is not the thing that shipped, and making that divergence loud in CI.

•         Making sure the devices in one location never end up with two primaries.

How we work

Remote, async-friendly, with real overlap hours. GitLab for code and CI, design-doc-driven decisions, and QA embedded with engineering. We validate against real hardware where it matters, because the artifact that ships is not always the one you develop against. QA owns the quality strategy and has a direct say in release go/no-go.