Your test suite is years of pre-AI IP. Locked up by drift and analysis cost. Reactivated in a sprint.

The Playwright drift

Playwright moves fast. A suite written in 2022 looks meaningfully different from one written today — page.click('selector') chains where getByRole would be cleaner, page.waitForSelector sprinkled where autowait already covers it, the occasional .only({}) someone forgot to delete before the merge. None of it is broken; all of it is drift.

Or your suite isn't on Playwright at all yet. It's a Selenium-Python pile, or a Cypress JavaScript pile, or a wiki page of manual steps your QA lead keeps meaning to convert. Same question — what's the cheapest way to get current? The sprint picks the highest-value tests in whatever you have, ships those in 30 days using our migration tools, and hands you a prioritized list of the rest for your team to work through.

Two paths the sprint covers

Path A — modernize an existing Playwright suite

Pin @playwright/test to the current major. Replace CSS-soup selectors with getByRole / getByLabel / getByPlaceholder wherever the page semantics make it possible. Drop redundant waitForSelector calls that autowait already covers. Re-shape the test config so retries, timeouts, and project matrices are explicit. Same logic, significantly cleaner suite, faster runs.

Path B — migrate onto Playwright

Selenium, Cypress, BDD .feature files, manual TestRail rows — any of those go in, Playwright in TypeScript or Python comes out. The conversion preserves the test logic; the output uses current Playwright idioms out of the gate. Your team picks the language; the sprint does the porting.

Where AI ends and your team starts

AI converts the test logic easily. Modernizing locators, swapping deprecated APIs for current ones, cleaning up redundant waits — that's mechanical work the model does well, and the output is reviewable as a diff.

The work that needs your team's hands is the cross-language, internal-utility, and custom-call layer. A Playwright suite that imports a shared helpers/login.ts file your team built. A Cypress suite wired to a custom command in cypress/support. Project-internal calls into your fixtures/seed.ts or shared BasePage that only your codebase sees. AI flags those, drafts a reasonable mapping, and notes which lines a senior should review before merge.

Why we draw the line there: those library-specific tweaks live in your repo for a reason. Your team adjusts them in minutes because they have the source, the build, and a green CI run as feedback. An outside team would take hours guessing. That said, we don't disappear at the line — the sprint includes paired work with your team on the translation + wrapper bits that need shared context. We don't auto-do it; we collaborate on it.

What the AI flags as missing

Playwright tests describe what to click but rarely describe what the page looks like, what the data flow assumes, or where the shared helpers live. The AI runs into those gaps constantly and is built to ask, not to guess.

Before the sprint runs the tests — during conversion — the AI flags ambiguities it can't resolve from the source alone. A spec that imports helpers/login.ts when the helper file wasn't in the upload, a step that depends on a custom page.evaluate block referencing internal app state, a fixture loaded with test.use({ storageState: 'auth.json' }) whose auth JSON wasn't provided — all flagged as questions for your team rather than silently guessed.

During the burn-in — when the converted test runs against your real site — the AI catches a different class of gap. A getByRole('button', { name: 'Submit' }) miss because the label is now "Save changes". An MFA prompt the test data doesn't cover. An assertion that expects toHaveURL(/\/checkout\/success/) but the URL drops a trailing slash. Each one becomes a clarifying question with a screenshot and a one-line ask.

These questions are the most valuable artifact of the sprint after the runnable suite itself. They surface gaps in your test code, your manual cases, and your documentation that nobody noticed because a human tester would just figure it out and move on. Now they're written down. Your team answers each one in a sentence, the suite re-burns, and the documentation gets better as a side effect.

What we accept and what we produce

Connect to what you have

Playwright tests usually live in a Git repo plus a TMS or two for the manual side. We connect to all of them.

• Repo upload — point us at the test directory; we read playwright.config.ts + your package.json so we keep your toolchain
• TestRail / Xray import — pull the manual side via API in addition to the uploaded code
• Reverse-proxy connection — for staging behind a firewall, a one-way reverse proxy lets the runner reach your environment without us touching your network
• Almost any artifact — Selenium scripts, Cypress specs, plain markdown plans, CSV / XML / JSON exports — if it describes a test in a structured way, the importer handles it