2.9 Autonomous Exploration

How to point an AI-driven explorer at a real running Chrome instance and a plain-English goal, and have it discover and draft a working test case by browsing the app itself.

Not enabled by default. Server-side CertiMind generation (URL/PRD scan, Plan Mode, Suite generation, the explorer) is off unless your organisation has it enabled. The recommended way to author tests today is your own coding agent (Claude Code, Cursor) connected to the CertiQA MCP server: it reads your code, creates the cases, runs only those cases, and repairs them from the failure report. Use the author_certiqa_tests MCP prompt. Contact your account team to enable CertiMind for your organisation.

What It Does

Instead of authoring steps by hand or recording a manual click-through, the explorer drives an already-running Chrome browser over the Chrome DevTools Protocol, describes each page’s interactive elements to CertiQA, asks what to do next toward your stated goal, performs that action, and repeats. It attaches to a tab you’re already signed into – the deliberate reason this is a local CLI rather than a server-side scanner: a server-side scan can’t see behind a login, but a browser tab you’re already logged into can.

Running It

How to Run an Exploration

• 1. Start Chrome with remote debugging enabled, e.g. chrome –remote-debugging-port=9222.
• 2. Run the explorer CLI (certiqa-explorer, provided on request during early access) with –token, –project, and –intent (your goal in plain English, e.g. “sign up for a new account and reach the dashboard”).
• 3. Scope it with one or more –allow and –deny flags so exploration can’t wander outside your app.
• 4. The explorer works through the flow, then submits everything it discovered as a draft – open the Copilot panel in your project to review and promote it into a real case.

chrome --remote-debugging-port=9222 &

certiqa-explorer \
  --token <api-token> \
  --project <project-id> \
  --intent "Add an item to the cart and complete checkout as a guest" \
  --allow https://shop.example.com \
  --deny "https://shop.example.com/admin" \
  --max 25

Scope Is Enforced Twice

Your –allow/–deny rules are checked both by the explorer itself before it acts, and independently by CertiQA’s own server-side scope check on every proposed action – so a scope mistake on one side doesn’t let exploration leave the intended app.

Why a Discovered Case Lands as a Draft

Exploration doesn’t write straight into a live suite. It submits its accumulated steps to the same AI-job and draft-review pipeline CertiMind’s URL scan and PRD generation use, with locator candidates and a confidence rating attached to each step, in the same TESTID > ROLE > TEXT > CSS > XPATH priority the rest of the platform relies on. You review and promote the draft from the Copilot panel exactly as you would a CertiMind-generated case, before it becomes something CI actually runs.

Before You Rely On What It Found

• –max caps page transitions, not total actions – set it generously enough for the flow you’re asking about, but low enough to bound an exploration that gets stuck looping.
• The explorer is a standalone CLI today – it’s not triggered from inside certiqa-app itself, so run it from a terminal (or a CI step) with a real Chrome instance available.
• Review the promoted case like any other AI-generated draft before relying on it in CI – exploration is a fast first pass at a test case, worth the same editing attention you’d give a recorded one.