AI‑Lens

AI QA agent

Point it at a product.
Get a map of it.

AI‑Lens explores a live application, builds a knowledge graph of its screens, journeys and business rules, then designs test cases from what it saw.

7products explored
41journeys walked
840graph nodes
435mobile test cases

Watch it work

See AI‑Lens explore a product.

A recorded walkthrough: AI‑Lens explores a live application, builds its knowledge graph and designs test cases from what it found.

Video hosted on Google Drive. Open in a new tab →

What AI‑Lens is

One QA agent, any product, any model.

AI‑Lens walks a live application, records what it finds in a single knowledge base, and designs, generates and runs tests from that record. It works with the tools your team already uses and the automation framework you already standardise on.

Grounded

Reads the real product

Tests reference controls and flows it observed, not ones it assumed.

Shared memory

One knowledge base

Screens, objects, journeys, rules, data and run history. Every run enriches it.

Human in the loop

Nothing self-commits

It proposes, a person reviews and merges, and execution replays reviewed code.

How it works

Requirement to report, in five stages.

Five stages read from and write back to one knowledge base. The engine is headless, so editors, CI and ticketing tools are thin clients over the same pipeline.

Scroll sideways to see the full diagram →

WHERE TESTERS AND DEVELOPERS ALREADY WORK WHAT ENRICHES THE KNOWLEDGE BASE VS Code extension Cursor extension Katalon Studio import / export CLI · CI pipeline headless DevRev tickets, workflows Jira · Azure DevOps plans, defects Live app exploration device & browser walk BRD · PRD · DRS requirements intake Jira · DevRev history defects, past runs CRM products held · proposed Voice of Customer complaints, NPS · proposed Voice of Machine logs, APM, crashes · proposed invoke · review · approve continuously enriches AI-LENS WORKBENCH · MODEL-AGNOSTIC · DEPLOY ANYWHERE One knowledge base screens · objects · journeys · business rules · test data · run history · every run makes the next one smarter 1 Requirement analysis parse, inventory, flag ambiguity 2 Test case design scenarios, techniques, priority 3 Script generation any framework · web and app 4 Execution on web & app any runner · no default 5 Reporting results, traceability, defects requirement IDs test design register specs · POM · data results · traces observed truth, not assumed fails on the app → regenerate SOURCES BRD · PRD · DRS user stories · epics existing manual cases TECHNIQUES risk-based · scenario boundary · negative → design register + RTM EMISSION TARGETS — ANY Playwright · Selenium Katalon · Appium REST / API · Cypress k6 · custom EXECUTION SURFACES web browser mobile app · Android / iOS API endpoints any runner you use SINKS Jira · DevRev defects RTM + coverage export dashboards · CI reports requirement defects · coverage gaps · traceability back to every requirement ID run evidence Provider adapter — model agnostic one interface; nothing above it knows which model or agent is running inference · stages 1-3 Claude GPT Gemini Llama · local any OpenAI-compatible DEPLOY THE SAME ENGINE ANYWHERE AWS EKS · EC2 · Bedrock OCI OKE · compute On-premises private data centre Engineer machine laptop + attached device knowledge base pipeline stage swappable — any tool or model feedback loop dashed = proposed, not yet built
Amber is the pipeline, teal the knowledge base every stage reads and writes, violet anything swappable (tool, framework or model), rose the two feedback loops. Dashed violet means proposed and not built: CRM, Voice of Customer and Voice of Machine are roadmap ideas, not shipped capability.

The five stages

01

Requirement analysis

In
BRD, PRD, DRS, user stories, Jira epics, existing manual cases
Does
Parses and inventories every requirement, assigns IDs, and flags ambiguity and contradiction instead of guessing past them.
Out
Requirement inventory with stable IDs
02

Test case design

In
Requirement inventory and the knowledge base
Does
Applies risk-based, scenario, boundary and negative techniques against what the application actually does, not only what the document claims.
Out
Test design register and traceability matrix
03

Script generation

In
Design register and observed objects from the knowledge base
Does
Emits to the framework you choose, such as Playwright, Selenium, Katalon or Appium. Scripts reference real controls, so they do not fail on locators that never existed.
Out
Specs, page objects, fixtures, test data
04

Execution on web and app

In
Reviewed, merged scripts
Does
Runs against the live product, web and mobile, through the runner you already use. A failure routes back to generation with the observed behaviour attached.
Out
Results, traces, screenshots, run evidence
05

Reporting

In
Run results across the suite
Does
Publishes results and coverage and raises defects, including requirement defects where the application and the specification disagree.
Out
Reports, coverage export, Jira and DevRev tickets

Built to swap

Any model

One provider adapter. Claude, GPT, Gemini, a local Llama, or anything OpenAI-compatible. Swapping one is a configuration change.

Any framework

The design register is framework-neutral. Only the emitter changes, and no runner is the default.

Any substrate

AWS, OCI, on-premises, or a laptop with a device attached. Same engine, same knowledge base.

No model in the unattended run

Generation proposes, a human reviews and merges, and execution replays reviewed code.

Proposed, not builtCRM, Voice of Customer and Voice of Machine would let test priority follow which products customers hold, which journeys they complain about and which paths crash in production.

Indicative architecture, not a specification.

New · AI‑Lens Visual

Check the build against the design.

Give AI‑Lens a mobile test build and the approved Figma file. It installs the app, signs in, walks every designed screen and compares each element with its Figma layer: colour, size, corners, font and text. The report shows Figma and app side by side with the measured values, separates real defects from differences that need a decision. It connects to Jira both ways: it raises the bugs it finds without duplicates, and reads the tickets designers raise, checks the build against them and posts the result back to the same ticket.

6 / 6screens reached
747checks matched
7problems on 5 screens
~3 minper full run
1 · The design: NovaBank in Figma3 min · Open in Loom →
2 · The check: AI‑Lens validates the app UI5 min · Open in Loom →

See it explore a product of your choice.

Paste a URL and watch AI‑Lens build a sample report. This demo is simulated, so nothing is sent to the site you enter.

Try AI Lens today