TestInspector generates browser tests from a natural language description, Gherkin scenario, or work item link by converting your input into structured test steps that execute in a real browser. You describe what to test — a login flow, a checkout process, an API response assertion — and the AI agent designs the steps, creates them in your suite, and streams its progress back to you as it works. The result is a set of editable, exportable, executable steps with no code required at any stage.

What You Can Type: Input Formats the AI Accepts

The Generate Tests chat interface accepts several formats:

• Free-form English — describe the scenario in plain language, for example: "Test that a user can log in with valid credentials and reach the dashboard."
• Gherkin (Given/When/Then) — paste a BDD scenario directly; the agent maps each clause to a test step.
• Azure DevOps or Jira work item links — the agent reads the ticket, extracts acceptance criteria, and proposes tests from the requirements.
• Follow-up instructions — after initial generation, send messages like "add a step to verify the error message" and the agent updates the test in the same session.

No template is required. If any step cannot be determined from your input, the agent asks for clarification in the chat before proceeding. You can also record tests directly from your browser using the TestInspector browser extension, which captures your actions as steps without typing anything.

How the AI Agent Designs Your Test

When you send a message, you see the agent's planning stream in real time — which suite to place the test in, how many steps are needed, what each step does. The agent validates every step before saving it: if a proposed action is not executable (unrecognised command, missing target, or unsupported syntax), the agent corrects it rather than saving an invalid record. Your suite always contains clean, runnable steps.

For tasks that require visual analysis — identifying a selector from a screenshot you share — a vision-capable AI pass runs on the image and suggests appropriate targets. For Azure DevOps or Jira work items, the agent parses the ticket into a structured test design brief before generating steps.

When generation is complete, the full set of new tests appears in your suite. If you close the tab and return later, the session history replays from storage. The AI does not re-run the generation; you see exactly what was produced originally.

How Test Steps Are Structured

Each step stores four things: the command (what to do), the target (which element or URL), the value (what to type, assert, or send), and its position in the sequence. This structure is what makes steps editable in the UI, exportable to different formats, and runnable across browsers without rewriting anything.

TestInspector supports 36 commands across these categories:

• Mouse interactions — click (left, right, double-click), hover, drag and drop
• Keyboard input — fill a field, press a key with optional Shift or Alt modifiers
• Navigation — open a URL, go back, refresh the page
• Assertions — verify element presence, visibility, text content, JavaScript expression results, and accessibility rule compliance
• Variable storage — store a value, extract text from an element, extract from a JavaScript expression
• HTTP requests — GET, POST, PUT, PATCH, DELETE with custom headers, a request body, and assertions on the response status or body
• Utilities — take a screenshot, run JavaScript, pause for a duration, exit the test as passing or failing

Steps marked as optional are skipped on failure without failing the test — useful for conditional UI elements that may or may not appear.

Variables and Environment Configuration

TestInspector resolves variables in step targets and values at run time using a four-level hierarchy. From highest to lowest precedence:

1. Runtime injection — values supplied when triggering a run via the API, used for CI/CD environment-specific configuration
2. Test-level variables — stored per test, encrypted at rest
3. Suite-level variables — shared across all tests in a suite, encrypted at rest
4. Org-level variables — defaults available to all suites in your organisation

Reference any variable in a step with double-brace syntax: {{VARIABLE_NAME}}. Three built-in tokens are also available:

• {{TIMESTAMP}} — the current Unix timestamp at run time
• {{ALPHANUMERIC}} — a random alphanumeric string, useful for generating unique test data
• {{TOTP:secret}} — a valid TOTP one-time password generated from your stored secret, enabling automated testing of 2FA login flows

Variable values at the test and suite levels are stored encrypted. No variable value is included in exported test files or run logs.

Running a Test and Reading Results

Triggering a run executes the test steps in sequence on a real browser — Chrome by default, with Firefox, Edge, and Safari also supported. As each step runs, the run panel shows live pass/fail status. If a step fails, the error and step details are displayed immediately so you can see exactly what went wrong without digging through logs.

Screenshots taken during a run are stored and linked to the run record. If you have set a baseline screenshot for a test, TestInspector automatically compares the new screenshot against it and shows you the difference percentage. If the difference exceeds your configured threshold, the test is marked as a visual regression. You can approve a new screenshot as the updated baseline from the test detail view at any time. For professional guidance on visual and functional test strategy, see Astaqc's software testing services.

Self-Healing: Automatic Selector Repair

When a step fails because an element selector no longer matches — a common result of routine UI changes — TestInspector can automatically attempt a repair. With auto-retry enabled on a test, the system analyzes the failure, generates alternative selector suggestions based on the current page structure and the step's original intent, and retries the step with the best candidate.

If the repaired selector succeeds, the test passes and the corrected selector is saved for future runs. No manual intervention is needed. The healing attempt is visible in the run log alongside the original failure. This significantly reduces the maintenance overhead of keeping a test suite current as the application evolves.

Export, Scheduling, and CI Integration

Tests created by the AI agent are not locked into TestInspector. From the Code View tab on any test, you can download it in several formats:

• Playwright TypeScript (.spec.ts) — each step maps to the corresponding Playwright API call. Optional steps are wrapped in try/catch. Variable references become JavaScript template literals. HTTP steps use the Playwright request context.
• Selenium IDE (.side) — the Selenium IDE 2.0 JSON format for playback in the Selenium IDE browser extension
• Gherkin — Given/When/Then BDD scenarios with step notes as comments, ready for import into BDD frameworks
• TestInspector JSON — the native format for re-importing the test into another suite or organisation

For scheduling, you can set any test or suite to run on a cron schedule (nightly at 02:00, for example), a fixed interval (every 30 minutes), or a one-time scheduled run. Run history records show whether each run was triggered manually, by a schedule, or by your CI/CD pipeline.

For CI/CD integration, the run trigger API accepts a configuration payload where your pipeline injects environment-specific values — base URLs, credentials, feature flags — that override all other variable levels for that run. A single test definition runs against staging and production with different configuration, with no changes to the test itself. See the outsource QA guide and manual testing services for context on combining automated and manual approaches.

AI-Generated Steps vs Coded Frameworks: Key Differences

Frequently Asked Questions

Can TestInspector test login flows that require TOTP two-factor authentication?

Yes. Use {{TOTP:secret}} in the step value where the OTP should be entered. TestInspector generates a valid one-time password from your stored secret at run time. The secret is stored encrypted and is never included in exported files or run logs.

What happens if the AI generates a step with an incorrect selector?

If the step fails at runtime and auto-retry is enabled, the self-healing feature generates alternative selector suggestions based on the current page and retries. If the retry succeeds, the corrected selector is saved for future runs. The attempt is visible in the run log.

Will my chat session history be lost if I close the browser tab?

No. TestInspector preserves your full chat and generation history. When you return to the Generate Tests view, your previous session replays from storage. The AI does not re-run the generation — you see exactly what was produced in your original session.

Can I test API endpoints without a browser interaction?

Yes. HTTP request steps (GET, POST, PUT, PATCH, DELETE) send real HTTP requests independently of any browser session. You configure the request headers and body, and assert on the response status code or body. These steps also export to Playwright's API testing context in the .spec.ts output.

How does environment variable injection work for CI/CD pipelines?

The run trigger API accepts a configuration object where your pipeline supplies variable values that override all other levels. Use this to run the same test suite against staging and production with different base URLs and credentials, without modifying the test. See Astaqc's test automation services for CI/CD integration guidance.

Does TestInspector support accessibility testing?

Yes. The assertAccessibility step type runs automated accessibility checks against axe-core rules and fails the test if violations are found above the configured severity level. You can scope checks to critical issues only, or include all violations. This step also exports to Playwright TypeScript with the AxeBuilder integration. See the AI in software testing guide for context on automated compliance checking.