Senior QA Engineer

Casado; Brazil; Remote; BRL 180,000 - 300,000; Full time

Job summary

Casado is seeking a Senior QA Engineer to own test strategy across on-device runtime, cloud services, and operator UIs for our Connected Device Fleet & Cloud Platform. You will design risk-based automation, implement it in CI, and drive end-to-end validation on real devices and in staging.

Join a large-scale, full-stack environment with AWS, MySQL data validation, and distributed systems patterns. Remote-friendly with overlap US Central / AU hours, you’ll help ensure reliability and

Qualifications

• Designs a test strategy and automates it in CI, not manual case-running.
• Familiar with risk-based coverage and automation-first mindset.
• Experience testing API contracts, JSON schemas, and JWT/JWKS.
• Strong SQL skills for data state validation (MySQL 8).
• Experience with Bash scripts for on-device and CI checks.
• CI quality gates in GitLab CI.

Responsibilities

• Test strategy across on-device runtime, cloud services, and operator UIs.
• End-to-end automation of device and cloud flows; on-hardware validation.
• API and contract testing; schema validation and data integrity checks.
• Load and performance testing of telemetry ingestion and services.
• Regression on high-risk surfaces; release-readiness validation with rollback checks.
• CI gates testing by behavior; raise automated-coverage floors.

Skills

Jest/TS

API testing

SQL

CI/CD

AWS

Distributed systems

QA strategy

Tools

Postman

Newman

MySQL

Bash

GitLab CI

Docker

Playwright

Selenium

Job description

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.

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)

• 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

• 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 ephemer
• 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.