Qpilot

Automating a browser test traditionally means picking a framework, writing locator logic, and maintaining it every time the UI ships. qpilot flips that: you describe the test in plain text — URL, credentials, numbered steps, expected results — and an AI agent interprets and executes it against a live Chrome session. The CLI is installed via npx, requires Node.js 18+ and Google Chrome, and uses Anthropic’s API under the hood to interpret each step. Results land per step with pass, fail, or warn status, and failure screenshots are captured automatically.

The standout behavior is how qpilot handles dynamic UIs. Because the agent reads the page visually and contextually rather than relying on stored selectors or XPaths, a redesigned button or a reordered form doesn’t break the test. The agent figures out where to click based on the description, not a brittle DOM path. This is the direct answer to the selector-drift problem that causes most Selenium maintenance overhead.

qpilot fits QA teams validating specific user flows — login, checkout, form submission — where the alternative is either no automation or a coded test suite nobody has time to write. It breaks down when you need tests running in parallel across environments, when your CI pipeline can’t provision a headed Chrome instance, or when Anthropic API costs per run become a line item. Teams hitting those walls typically reach for Playwright or a managed browser testing platform that separates execution infrastructure from test authoring.

The OTP handling is worth noting specifically: when the agent encounters a one-time password prompt mid-run, execution pauses and surfaces the prompt to you directly, then picks up after you respond. This means two-factor authentication flows aren’t blocked outright — you review before it continues — though it does break fully unattended execution for any flow with MFA.