Kane CLI Exploration Learns Your Web App Before Anyone Writes a Test

Exploration Covers the Whole App Instead of One Flow

Most AI testing runs follow a single path that someone described, such as login or checkout. Kane CLI Exploration goes through every screen, junction and flow it can reach, the way a new QA engineer clicks around a product during their first week on the team.

As the exploration agent moves through the app, it records three kinds of information into the map:

• Controls - the buttons, forms, menus and input fields on every screen the agent reaches.
• Flows - the journeys that connect one screen to the next, along with the links coming into and going out of each screen.
• States - the different versions of the same screen, such as a form before and after it shows a validation error.

The Kane CLI 0.10.0 release notes describe how a run scales: Exploration drives up to 20 cloud browsers at once on HyperExecute and opens a new browser only when the explorer has work for it. The release notes also say the live view streams each browser's picture at up to 15 frames per second, so you can open any one browser session and watch what the agent is doing on that page.

Start an Exploration From Your Terminal

An exploration starts from the same Kane CLI install that runs your other tests. The Kane CLI getting started guide covers the install and login in detail.

npm install -g @testmuai/kane-cli
kane-cli login
kane-cli explore run --url https://yourapp.com

On a terminal, kane-cli explore run opens a short setup form and a review before it queues the run on HyperExecute. The command exits once the run is queued, so the exploration keeps going on the cloud after you close the terminal.

A handful of commands and flags control what the exploration does next:

• --prompt - tells the explorer what to cover and why, such as "Explore the checkout and account settings".
• --policy read_only - blocks writes at the route and browser level, and the explorer never acts on delete, sign out or pay controls under this policy.
• --deny - names a control, such as "Archive", that the explorer must never click under any policy.
• --max-parallel - sets how many browsers run at once, from 1 to 20 on the cloud.
• kane-cli explore view - serves a live graph of the exploration map on your machine while the run is in progress.
• kane-cli explore stop - aborts a queued run, or stops a running one cleanly after every result has been sent.

Anything a page displays as a secret, such as a password, card number, PIN or bearer token, is masked before it leaves the worker. Those values never reach the event log, the terminal log or an evidence pack.

One Exploration of a Demo Store, Run Six Times

To show what an exploration produces, the screenshots below come from one exploration of automationexercise.com, a public demo store, run six times on HyperExecute on 24 October. They are taken from the upcoming Exploration view in Test Manager, which is coming next so the whole team can browse finished explorations without touching the terminal.

The Map

After the sixth run, the exploration map held 15 screens in 4 business areas: Home and help, Brand products, Shop and cart, and Account. Kane CLI grouped the screens into those business areas on its own, and it tagged each screen as Entry, New or Changed against the previous run.

The overview tab sums up the same run in one line: 2 flows broke, 20 high-severity findings need review, and the agent is stuck at sign-in. The sign-in item comes with an Add Sign-in action, because the exploration agent cannot get past a login screen until someone gives it credentials.

The Flows and Findings

The exploration recorded 21 flows, and 14 of them worked end to end. Five flows changed since the previous run and wait for the next run to re-verify them, while two broke: "Contact support" and "Contact support or manage subscription" both stop at the Contact Us screen.

The exploration also raised 64 findings: 20 high, 35 medium and 9 informational. The most common high-severity finding, "Buttons must have discernible text", appeared on all 15 screens, and "Form elements must have labels" appeared on 3 of them.

The Runs

Every run adds to the same map, and the Activity tab shows what each run contributed. The first four runs ended before they reached a screen, which is why the table shows them as Found nothing.

Run 5 took 8 minutes and added 11 screens, 11 flows and 42 findings. Run 6 took 5 minutes and added 4 more screens, 10 flows and 23 findings on top of that map.

Exploration Flags Bugs Nobody Asked It to Look For

You don't have to tell Kane CLI Exploration what to test, because the exploration agent decides where to go next and checks every screen it reaches. The Kane CLI 0.10.0 release notes list the detectors that run on each screen:

• Accessibility - axe-core checks, such as controls that a screen reader has no name for.
• Console and network - JavaScript errors in the console and requests that fail.
• Broken links - links that lead to an error or an empty page.
• Performance - slow requests and other performance problems on the screens the agent visits.

The demo store shows why the accessibility detector matters on its own. A button with no discernible text breaks WCAG success criterion 4.1.2, which requires the name and role of every user interface component to be programmatically determinable, and that one problem showed up on all 15 screens of the store.

Each finding carries its own evidence: a clip of what happened, before and after screenshots with the acted control boxed, Network and Console tabs, a cause chain and a verdict. A finding starts as open, and a person moves it to bug, resolving, resolved or discarded, with a History tab that records who changed what and when.

The Bugs count in the demo overview reads 0 for that reason, because none of the 64 findings had been triaged into a bug yet. Finding issues this way works best on the parts of an app that no existing test suite covers, since nobody wrote down how those parts were supposed to behave.

The Exploration Map Becomes Your Testing Context

Kane CLI Assurance normally reads requirements and turns them into use cases and acceptance criteria, as the PRD to evidence walkthrough shows. When an app has no requirements to read, the exploration map takes that role, and the kane-cli explore context command keeps the map switched on as assurance context by default.

Here is how Exploration and Assurance work together on one app:

• You point Kane CLI Exploration at the URL of your web app with kane-cli explore run.
• The exploration agent walks the app in parallel cloud browsers and saves a map of its screens, controls and flows, along with every finding.
• Kane CLI Assurance reads that map as context and writes use cases and acceptance criteria from it. In the demo store, Assurance wrote 8 use cases with 23 test cases from the map.
• Kane CLI runs the resulting tests and seals an Evidence Pack for each run, with the screenshots, network log, console output and page state behind every step.
• The tests go into CI and run on every future pull request, so a bug that Exploration found once stays covered.

Coverage is reported per acceptance criterion through kane-cli cover, so you can see which parts of the explored app a test has proven and which still have gaps. The tests and use cases land in TestMu AI Test Manager, next to the rest of your test cases.

Use Cases for Kane CLI Exploration

Teams that already run Playwright, Selenium or Cypress keep those suites as they are. Exploration adds tests for the parts of the app that nobody had documented, and every gap it closes turns into a test that runs in the same pipeline as the rest of your automation, as covered in Kane CLI in CI/CD.

Kane CLI Exploration earns its place in a few situations that most QA teams will recognise:

• Legacy apps - the original specs are lost or out of date, and the team needs a map before it can change anything safely.
• Agent-built apps - a coding agent shipped the app faster than anyone could document it, which is the gap described in vibe coding's verification problem.
• Inherited products - a new team has just taken over the product and needs to learn its screens and flows before writing a single change.

Exploration does not replace human exploratory testing, which still depends on a person's judgement about what matters to users. Exploration covers breadth across every reachable screen, and a QA engineer decides which findings are real bugs and which flows deserve deeper tests, alongside the exploratory testing tools the team already uses.

Exploration Launches for Web Apps on KaneAI Max

Kane CLI Exploration is available today for web applications, while the rest of Kane CLI already tests both web and mobile apps from the same terminal. Exploration comes with the KaneAI Max plan, which includes three exploration sessions per licence.

Exploration runs on HyperExecute by default, so a run does not depend on your laptop staying awake. A run that no machine picks up within 10 minutes ends with a clear failed:vm_never_started reason instead of hanging, according to the Kane CLI 0.10.0 release notes.

Run Your First Exploration

Try Kane CLI Exploration on the part of your app that your team knows least. Install Kane CLI, run kane-cli explore run with your URL and the read_only policy for a first pass, then open kane-cli explore view to read through what it finds.

npm install -g @testmuai/kane-cli
kane-cli login
kane-cli explore run --url https://yourapp.com --policy read_only