Hire an AI test automation engineer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A short list of flows worth a browser test, and which checks to move to unit or API tests.
• Test code with role-based selectors, data set up through the API and no hard waits.
• The base files, such as a login fixture, data helpers and a Playwright config that keeps traces.
• A CI file that splits tests across machines and keeps traces when a test fails.
• A flake table with the cause and the fix for each flaky test you shared.
• A checklist to run each new test ten times before you merge it.

How it does the job well

• Use only routes, labels and API calls the user gave you. Use placeholders like <your API url> for the rest and say so.
• Do not say a test passes unless the user pasted a result that shows it. Say "not run" for everything else.
• Targets in the original (99.5 percent pass rate, a suite under 10 minutes) are goals to aim for. They are not results.
• Check install and CI commands against the tool's current docs before you tell the user they work.
• Do not log in with real customer accounts or send real emails. Use test data and a test environment.
• No hard sleeps. Ever. waitForTimeout(3000) is a flake with a countdown timer. Wait on conditions: element state, network response, URL change — never wall-clock time.
• Tests own their data. Every test creates what it needs (via API, not UI) and tolerates parallel siblings. A test that depends on another test's leftovers, or on "the seed user", is already broken.

Mistakes it avoids

• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: Your browser tests fail at random, and your team re-runs them until they go green.

• Scope. The flows that deserve a browser test and the checks that move to unit or API tests.
• Setup files. Data helpers, a once-per-worker login and a config that keeps traces for failures.
• Tests. Test code per flow with role-based selectors, owned data and no hard waits.
• CI. A workflow file that splits tests, keeps failure files and blocks a merge on a failure.
• Flake triage. Each flaky test with its symptom, likely cause and fix.
• Run checklist. The commands to repeat each test ten times and a list of what has not been run.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Map the key flows. It lists the flows whose failure would hurt most, and moves anything a unit or API test can prove out of the browser.
• Build the base. It sets up data helpers that call your API, a login once per worker, selector rules and a config that keeps traces.
• Write steady tests. It picks elements by role and name, waits on conditions and replies, and gives each test its own data.
• Wire up CI. It splits tests across machines, keeps traces, screenshots and videos for failures, and blocks the merge on the stable suite.
• Triage flakes. It matches each flaky test to a likely cause, such as shared data or a slow wait, and gives the fix, not a workaround.
• Prove it. It asks for ten clean runs per new test and tracks pass rate, run time and flake rate over time.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id testing-test-automation-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/testing-test-automation-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The flows that must never break, in plain words, such as "a customer adds a product and pays".
• The tool you use or want, Playwright or Cypress, and your language, such as TypeScript.
• Your existing test files and CI config, pasted or uploaded (optional).
• The failing or flaky tests, with the error text, the CI log or a trace (optional).
• How test data is made today, such as an API, a seed script or by hand (optional).

Helpful context (optional)

• The trace or CI log of a failed run.
• Your app's API docs, so the data helpers use the real calls.

Tools and access

• Claude Code or Codex: They can read your repo, write the test files, run the suite and repeat each test ten times.
• Claude, ChatGPT or Gemini: In a plain chat they can write and review test code from what you paste, but they cannot run it.

Functions and deliverables

• Test automation engineer agent: Get stable Playwright or Cypress browser tests, a CI setup and a fix for each flaky test, so failures mean real bugs and not bad timing.
  • A short list of flows worth a browser test, and which checks to move to unit or API tests.
  • Test code with role-based selectors, data set up through the API and no hard waits.
  • The base files, such as a login fixture, data helpers and a Playwright config that keeps traces.
  • A CI file that splits tests across machines and keeps traces when a test fails.
  • A flake table with the cause and the fix for each flaky test you shared.
  • A checklist to run each new test ten times before you merge it.
  Source: Michael Sitarzewski and Agency Agents contributors.
• Cypress flaky test fixer: Give it an existing Cypress suite and version. Get flaky patterns and removed APIs checked, with test-only fixes and verification steps.
  • A list of flake-prone code and removed APIs, with file and line
  • Fixed test code that waits on real conditions, not fixed delays
  • A report table with counts before and after each fix
  • A list of problems that need an app change, not a test change
  Source: GitHub Copilot community.
• Playwright browser automation scripter: Describe a browser task. Get a custom Playwright script and, when its browser setup is ready, run results and screenshots.
  • A Playwright script written for the task
  • The script run in a visible browser
  • A report of what happened
  • Screenshots of the result
  Source: sickn33.
• Flaky test fixer: Find why your Playwright test is flaky and get it fixed. Give it a failing test and it finds the cause, fixes it and proves it stays stable.
  • Reproduction of the failure
  • Cause sorted into one of four types
  • Fix applied to the test
  • Repeat-run results showing it is stable
  Source: Alireza Rezvani.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• Your browser tests fail at random, and your team re-runs them until they go green.
• You have no end-to-end tests for sign-up or checkout and want a first set that you can trust.
• Your test suite takes too long in CI and you want it split across machines.
• You are moving from Cypress to Playwright, or the other way, and want the tests moved with care.

Limits to check before starting

• You have a finished test run and want it sorted by cause and risk: use the Test results analyst.
• You want a page-by-page check with screenshots and no code: use the Visual QA evidence collector.
• You only need to test an API, not a browser: use the API test planner.
• You want an accessibility audit: use the Accessibility auditor.
• You do not use Playwright or Cypress, such as Selenium or a mobile app test tool: this agent may not fit.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack. Add it to your AI as a skill, or paste SKILL.md and then references/source-agent.md into a new chat.
• Say which tool and language you use, and list the flows that matter. For flaky tests, paste the test, the error text and the CI log.
• Ask for the plan first: List the flows that need browser tests and what moves to unit or API tests. Do not write code yet.
• Approve the list. Then ask for the base files first (data helpers, login fixture, config) and the tests second.
• Run the tests yourself. For each new test, run it ten times, for example with npx playwright test --repeat-each=10. Claude Code or Codex can run it for you if you allow it.
• Paste any failure and its trace back and ask for the cause. Do not merge a test that needs a retry to pass.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/testing-test-automation-engineer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.