Hire QA Automation Engineers remotely from our vetted global talent

A QA automation engineer owns the automated test suite as a piece of engineering: the framework code that drives the browser or device, the fixtures and factories that produce hermetic test data, the CI integration that runs everything in parallel, and the flake discipline that keeps the signal trustworthy. The role exists because once a test suite passes a few hundred specs, maintaining it stops being a side job a QA engineer can fit between manual passes and becomes full-time framework work. At Terminal, QA automation hires are the engineers product teams reach for when the automation suite is substantial enough that someone has to own it.

Where the role sits in the QA org: The distinction that matters at hiring time.

• QA automation engineers are specialists in test automation as engineering. They build, maintain, and scale automated suites full-time

• QA engineers are generalists who split time between manual testing, exploratory work, and lighter automation

• Manual QA testers focus on human-driven testing and do not write automation code

• SDETs (software development engineers in test) build the underlying test infrastructure, harness, and tooling. QA automation engineers consume that infrastructure to ship suites

• Get the title right before the hire. The day-to-day differs more than the resumes suggest

Web automation stacks: Where most of the role's surface area lives.

• Playwright as the dominant choice for new work, with built-in auto-waiting, parallelism, and trace viewer

• Cypress still entrenched on existing suites, especially component testing and developer-owned tests

• Selenium for legacy estates and cross-browser coverage at scale where Playwright's grid story does not fit

• WebdriverIO when the team needs a single framework that spans web, mobile web, and native mobile

• An opinion on which tool fits the team, not a religious preference

Mobile and API automation: The surfaces a serious automation engineer covers beyond the browser.

• Mobile automation with Appium for cross-platform suites, Detox for React Native, Maestro for fast flow-level tests

• Native mobile coverage with XCUITest on iOS and Espresso on Android when the team owns the apps end to end

• API testing with RestAssured, Karate, Tavern, Postman runners, or Bruno, picked by language fluency on the team

• Performance and load testing with k6 for developer-friendly scripting, JMeter or Gatling for heavy load patterns, Locust for Python shops

• Visual regression with Percy, Chromatic, Applitools, or Playwright snapshot testing where pixel drift matters

Framework patterns the role applies: The structural choices that decide whether the suite scales.

• Page Object Model and Screenplay patterns for separating intent from implementation

• Fluent assertions and fixture-based setup that keeps specs readable a year later

• Hermetic test data via factories, seed scripts, or API setup hooks rather than shared database state

• Parallel execution, sharding, and retry strategy configured deliberately at the CI layer

• Test result analytics and flake detection feeding back into the suite, not just dashboards

Common stacks worth knowing: Real-world QA automation engineers usually go deep in one or two combinations.

• Playwright with TypeScript, GitHub Actions, and Playwright trace viewer for product teams shipping web at speed

• Cypress with TypeScript or JavaScript, Cypress Cloud or Sorry Cypress, and component testing on the same harness

• Selenium with Java or Python, TestNG or pytest, and Selenium Grid or BrowserStack for cross-browser scale

• Appium with WebdriverIO and Sauce Labs or BrowserStack for cross-platform mobile coverage

• k6 with TypeScript scripts and Grafana Cloud k6 for load and performance suites that live alongside functional tests

The case for a QA automation specialist is almost always a suite-complexity argument. When the automated test suite is large enough to need dedicated framework engineering, when CI runtime or flakiness is a real bottleneck, or when test infrastructure needs a full-time owner, hiring an engineer who lives in that work pays back quickly. The case against shows up on small suites where a QA engineer or a backend engineer can keep the tests green as part of a generalist role.

Suite size justifies dedicated ownership: The threshold where automation becomes its own engineering discipline.

• Hundreds or thousands of end-to-end and integration tests across web, mobile, and API surfaces

• Multiple suites running on different cadences: pre-merge, nightly, release-candidate, production smoke

• Framework code that other engineers depend on, including custom fixtures, helpers, and reporting

• Coverage gaps that need an owner who can prioritize what to automate next, not just write what is asked

CI runtime or flake is a real bottleneck: When the test suite is in the critical path of every deploy.

• Pipelines where end-to-end tests dominate wall-clock time and parallelization is the lever

• Flake rates high enough that engineers re-run jobs reflexively, eroding trust in green builds

• Quarantine and root-cause discipline that needs someone tracking flakes, not deferring them

• Sharding strategy, retry logic, and test selection that need tuning, not defaults

Test infrastructure needs an owner: When the framework is itself a piece of internal software.

• Custom assertion libraries, fixture factories, and test data management used across teams

• Reporting and analytics tooling that feeds engineering leadership, not just the QA backlog

• Accessibility automation, visual regression, and performance gating integrated into the same pipeline

• Tooling decisions that affect every engineer's daily workflow and deserve dedicated thought

AI Fluency multiplier: Agentic AI workflows have changed how QA automation engineers ship suites, and the gains compound on test code.

• An AI Enabled engineer running Cursor or Claude Code with human-in-the-loop review can generate test cases from user stories or design specs, scaffold Page Objects, and write fixtures in a single session

• An AI Native engineer orchestrates agents to investigate flaky tests autonomously: pull recent failures, correlate with code changes, propose root causes, and open the fix

• Autonomous regression scoping where agents read a pull request diff and propose the test surface that needs coverage, not just rerun the whole suite

• Terminal classifies every engineer in AI Assisted, AI Enabled, or AI Native tiers and surfaces those signals at hire time

When not to hire a QA automation specialist: Generalists win on small suites.

• Teams of 2 to 10 engineers where a QA engineer can maintain a few dozen automated tests alongside manual work

• Codebases where developers own their own tests and an SDET already runs the framework

• Early-stage products where the feature surface changes faster than any test suite could keep up

• Hire a QA engineer when the breadth of testing work matters more than the depth of automation

A senior QA automation engineer's job description is broader than the job posting suggests, but the day-to-day is concrete. Here is what they actually own.

Test design and authorship: The default unit of work.

• Translate acceptance criteria, user stories, or bug reports into automated specs that fail for the right reason

• Pick the right level of the pyramid: unit, integration, contract, or end-to-end. Refuse to automate at the UI layer what belongs in a unit test

• Cover happy paths, edge cases, and the long tail of regressions that have bitten before

• Pair with product and engineering on what changed before writing the spec, not after

Framework engineering: The structural work that decides whether the suite scales.

• Maintain and extend the Page Object layer, fixture factories, and shared helpers other engineers depend on

• Keep the assertion vocabulary readable so a spec reads like a sentence, not a transcript of clicks

• Introduce new test types (visual, accessibility, performance) when they earn their maintenance cost, not because the tool is shiny

• Refactor the suite when growth pressures it, the same way an application engineer refactors production code

Flaky test discipline: The senior bar is killing flakes, not tolerating them.

• Detect flakes with retry analytics, dashboards, and per-spec failure-rate tracking

• Quarantine flakes immediately so they stop blocking unrelated work, then investigate root cause

• Distinguish timing issues, data leaks, environment instability, and real product bugs hiding behind a flake

• Remove or rewrite flakes; never let a quarantined test live forever

CI integration and runtime: The senior bar is debugging a slow pipeline without guessing.

• Configure parallel execution and sharding so wall-clock runtime matches the team's deploy cadence

• Tune retry logic, test selection, and pre-merge versus nightly splits to keep signal high and runtime low

• Integrate with GitHub Actions, CircleCI, Buildkite, Jenkins, or the team's CI of choice

• Surface failure analytics that help engineering leadership see trends, not just individual red builds

Test data management: Hermetic data is what separates a senior suite from a brittle one.

• Build factories and fixtures that produce isolated test data per spec, not shared state

• Seed scripts, API setup helpers, and teardown hooks that leave the environment in a known state

• Synthetic data generation and anonymized production samples where realism matters

• Strategy for stateful flows (auth, checkout, multi-step wizards) that does not rely on order of execution

Accessibility, visual, and performance automation: The coverage that earns its place in the pipeline.

• Accessibility automation with axe-core, Pa11y, or framework-equivalent, gated as part of CI

• Visual regression with Percy, Chromatic, Applitools, or Playwright snapshots, scoped to the components that actually change look

• Performance budgets with Lighthouse CI or k6 in pre-merge runs so regressions get caught before launch

• Coverage that fits the product, not coverage cargo-culted from a blog post

Cross-team collaboration: A lot of the work happens outside the editor.

• Partner with engineering on testability: pushing back when a feature is hard to test by design

• Partner with product on acceptance criteria that translate cleanly to automation

• Partner with SDETs and DevOps on the underlying harness, runners, and reporting infrastructure

• Mentor engineers on writing their own tests, raising the floor of the whole team's automation

The skill bar separating a senior QA automation engineer from a generalist is depth in a few areas, not breadth across all of them. Terminal screens for both. Only the top 7% pass our screening, and the skills below are the ones that come up in technical interviews.

Programming depth, not scripting comfort: Senior automation engineers write production-quality code, not glue.

• JavaScript and TypeScript at depth for Playwright, Cypress, and WebdriverIO work, including async control flow and module design

• Python with pytest, fixtures, and Selenium bindings for the large share of suites that live in Python

• Java with TestNG, JUnit 5, Selenium, and RestAssured for enterprise stacks

• Kotlin with Espresso, or Swift with XCUITest, when the role spans native mobile

• Comfort writing reusable libraries, not just specs that copy-paste

Web automation at depth: Production experience in at least one modern web automation framework.

• Playwright including auto-waiting, locators, fixtures, parallel projects, and the trace viewer for debugging

• Cypress including commands, intercepts, component tests, and the limits of its single-tab execution model

• Selenium including grid setup, explicit waits, and a working knowledge of where it breaks down compared to Playwright

• An opinion on when each tool fits and the discipline to recommend a migration when the current choice is the wrong one

Mobile and API automation: Where the role extends beyond the browser.

• Appium with the WebdriverIO or Java client, plus device farm fluency (Sauce Labs, BrowserStack, AWS Device Farm)

• Detox for React Native or Maestro for fast flow-level mobile tests on top of native or cross-platform apps

• API testing with RestAssured, Karate, Tavern, Postman runners, or Bruno, including schema validation and contract testing

• Performance and load testing with k6, JMeter, Gatling, or Locust where the suite has to verify behavior under realistic load

Framework patterns and test design: The structural judgment that decides whether a 500-spec suite survives a year.

• Page Object Model, Screenplay pattern, or screen-level abstractions picked deliberately, not by default

• Fluent assertion design and a readable test vocabulary

• Fixture and factory design for hermetic test data, including handling of stateful flows

• Understanding of the test pyramid and the discipline to refuse to automate at the UI layer what belongs lower

CI integration and flake discipline: Senior automation engineers run their suites in production CI, not just on a laptop.

• Parallel execution, sharding, and retry strategy on GitHub Actions, CircleCI, Buildkite, or Jenkins

• Flake detection with per-spec analytics, quarantine workflows, and root-cause discipline

• Test-result reporting and dashboards that engineering leadership can read without translation

• Pre-merge versus nightly split tuned so the suite is in the critical path only where it earns the runtime

Accessibility and visual automation: Beyond functional checks: the coverage that catches what users actually see.

• Accessibility automation with axe-core, Pa11y, or framework-equivalent, including WCAG 2.2 AA criteria fluency

• Visual regression with Percy, Chromatic, Applitools, or Playwright snapshots, scoped to changes that matter

• Performance gating with Lighthouse CI or comparable tools when the product treats Web Vitals as KPIs

• Knowledge of where automated tools stop being useful and manual testing has to start

AI Fluency: The capability shift that is reshaping engineering output.

• Daily use of Claude Code, Cursor, GitHub Copilot, or comparable AI coding assistants

• Comfort generating test cases from user stories or design specs with LLM-driven workflows, then editing for accuracy and coverage

• Agentic flake investigation: pointing an agent at a failing spec, recent commits, and traces to surface root cause faster than manual triage

• Autonomous regression scoping where agents read a pull request diff and propose which tests need to run, not just rerunning the entire suite

• AI Enabled or AI Native tier per Terminal's standard. The engineer either uses AI tools to compound their output significantly, or builds agentic workflows directly

Soft skills that matter: The non-technical bar is real.

• Clear written communication. Most automation work happens in pull requests, design docs, and async threads

• Pragmatism on coverage. The senior tell is refusing to automate things that should not be automated, not chasing 100% UI coverage

• Mentorship instinct. Senior engineers raise the floor of the whole team's testing discipline

• Calm under release pressure. The flaky suite the night before a launch, the regression that slipped past pre-merge, the production smoke test that just lit up