The TestInspector browser extension records user interactions with a web application and converts them into structured test steps directly in your TestInspector account. It captures clicks, inputs, form submissions, and navigation events without requiring you to write any code or describe steps manually, making it the fastest path from observing a workflow to having a runnable test. Once recording is complete, the test is immediately available in TestInspector's runner, executable across Chrome, Firefox, Edge, and Safari via Selenium.

What the TestInspector Browser Extension Does and How It Works

The extension operates as a passive observer of browser activity during a recording session. When you activate recording and navigate through a web application, the extension captures each interaction — a click on a button, text typed into an input field, a page navigation, a form submission — and translates it into the corresponding TestInspector step type: a click step, a type step, a navigate step, a submit step.

The recorded steps are structured identically to steps created through TestInspector's chat interface or built manually in the step editor. There is no difference in format or capabilities between a recorded step and a manually authored step. Both can be edited, reordered, duplicated, or deleted after recording. Both can include variable references using TestInspector's {{VAR}} syntax, assertion conditions, and wait logic. Recording accelerates step creation; the test definition format is the same regardless of how it was created.

Selector capture is handled automatically during recording. When you click an element, the extension captures the element's identifier in a priority order designed to prefer stable, meaningful selectors over fragile positional ones. If the element has an id, that is used. If not, the extension looks for data-testid or data-test attributes, then falls back to a CSS selector based on the element's class and tag structure. The captured selector is editable after recording — if the extension captured a fragile selector you know will change, you can replace it before saving the test.

The extension connects to your TestInspector account through the same authentication session you use in the web interface. Recordings save to the suite you designate before starting the recording session. You can create a new suite from the extension panel or select an existing one, so recorded tests are organized from the moment they are saved. For context on where browser recording fits within a broader automation approach, see Astaqc's test automation services and the manual vs. automated testing guide.

Recording a Test: Step-by-Step Flow with the Extension

The recording flow is designed to minimize interruption to the natural interaction pattern. You set up the recording before you start the workflow, then interact with the application exactly as a real user would. You do not switch between the extension panel and the application mid-recording; the extension captures interactions passively in the background.

The sequence for starting a recording is as follows. Open the TestInspector extension panel from the browser toolbar. Select or create the suite where the recorded test should be saved. Enter a name for the test. Click the record button. The extension enters recording mode — a visible indicator appears in the toolbar and optionally as an overlay on the page. Navigate to the starting URL of the workflow you want to capture. Execute the workflow in the application exactly as a user would: enter login credentials, click through navigation menus, fill in form fields, submit data, verify landing on the correct page.

When the workflow is complete, click the stop button in the extension panel. The extension presents a list of captured steps for review before saving. You can scroll through the list, delete any spurious steps that were captured by accident — a misclick, a navigation you do not want in the test — and review the selector captured for each interaction. Clicking save sends the steps to TestInspector and creates the test in the selected suite.

The review step before saving is important for test quality. Recordings of real user flows often include navigations or interactions that are not part of the test scenario — opening a different tab, accidentally hovering over a dropdown that triggered a capture event. The review list makes these visible before they become part of the test definition. Deleting them during review costs a few seconds and avoids a brittle test that fails because it expects a navigation step that was a recording artifact.

After saving, the test is available immediately in the TestInspector interface for editing, running, or inclusion in a suite schedule. For guidance on building a software testing strategy that incorporates both recorded and manually authored tests, see Astaqc's software testing services.

Editing Recorded Tests and Adding Assertions

A recording captures interactions — what the user did — but a complete test also needs to verify outcomes. Assertion steps are not automatically generated from recording because the extension cannot infer which page states matter to the test: a navigation step that ends on /dashboard tells the recorder the page loaded, but it does not specify whether the page should display a specific heading, contain a success message, or be free of accessibility errors.

Assertions are added to a recorded test in the step editor after recording is complete. TestInspector provides several assertion types that can be inserted between or after recorded interaction steps. A text assertion checks that a specified element contains expected text. A visibility assertion checks that an element is present and visible. A URL assertion checks that the current URL matches an expected pattern. An HTTP response assertion, available in HTTP request steps, checks status codes and body content. An accessibility assertion, powered by axe-core, checks the page against WCAG rules at a specified severity level.

Variable substitution can be applied to recorded steps after the fact. A recorded step that types a hardcoded password into an input can be converted to use {{PASSWORD}} by editing the step's value field. This is the standard pattern for converting a recording made with real credentials into a test that uses the variable store for credential management — record with actual values to capture the right selectors and interaction sequence, then replace specific values with variable references in the editor.

Self-healing is available for recorded tests on the same basis as manually authored tests. When a step's captured selector fails to locate an element during a run, TestInspector's auto-retry mechanism uses AI selector suggestions to attempt recovery, trying semantically similar selectors derived from the element's context. If recovery succeeds, the run continues and a suggestion is surfaced for updating the selector permanently. If recovery fails, the step fails and the run report identifies the selector breakdown, with the suggested alternatives available for manual review.

For organizations that need to maintain large suites of recorded tests through UI changes, see Astaqc's QA team service and the complete software testing guide for strategic context on test maintenance planning.

When to Use the Extension vs. the Chat Interface

TestInspector provides two authoring approaches: the browser extension for recording interactions and the AI chat interface for generating test steps from natural language descriptions. Both produce the same step format and both are editable after creation. The choice between them depends on what information is easier to express — a live demonstration of the workflow or a textual description of it.

Both approaches are composable. A common pattern is to use the extension for the interaction sequence — which is faster to record than to describe — and the chat interface for assertions and HTTP steps, which are easier to specify in natural language. The resulting test combines recorded interaction steps with chat-generated assertion and API validation steps, all in a single test definition.

The AI interface through TestInspector's MCP token integration in Claude Code or Cursor can also add steps to an existing recorded test. See TestInspector's MCP documentation for the current list of available MCP operations.

Running and Maintaining Recorded Tests

Recorded tests run in TestInspector's Selenium-backed browser environment identically to manually authored tests. The runner executes each step in sequence across the specified browsers — Chrome, Firefox, Edge, or Safari — and streams results in real time via WebSocket. The run report shows each step's status (pass, fail, skipped), the selector that was targeted, the action taken, and any assertion outcomes.

Scheduling applies the same way to recorded tests. A recorded test can be included in a suite that is scheduled to run on a cron expression, a fixed interval, or a one-time future trigger. If the application under test is in active development, a nightly scheduled run of recorded regression tests provides a daily signal on whether UI changes have broken recorded workflows without any CI integration required.

The primary maintenance trigger for recorded tests is selector drift — when application markup changes enough that a recorded selector no longer identifies the target element. The self-healing auto-retry handles transient cases, but structural changes require selector updates. TestInspector surfaces failed selectors with AI-suggested replacements in the run report. For most selector drift cases, the fix is accepting the suggested replacement rather than manually inspecting the application's DOM.

Practices that reduce recorded test maintenance cost:

• Prefer elements with stable identifiers (id, data-testid) as interaction targets during the recording session. If the application under test uses positional selectors or auto-generated class names, add stable test attributes to the application before recording.
• Record with variable references for dynamic values rather than hardcoded strings. A test that types {{USERNAME}} instead of a literal email address survives credential rotation without step edits.
• Keep recorded tests short and focused. A recording of an entire 40-step workflow is harder to maintain than four recordings of 10-step sub-flows that can be combined in a suite run sequence.
• Run recorded tests on a schedule against your staging environment before merging to main, so selector drift is caught at the point of the UI change rather than discovered in production.

For teams managing large volumes of recorded tests through frequent UI changes, Astaqc's test automation services include architecture and maintenance strategy for browser-based automation suites. The guide to outsourcing QA covers when to bring in external expertise for test maintenance at scale.

Frequently Asked Questions

Which browsers does the TestInspector browser extension support for recording?

The TestInspector browser extension is a Chromium-based extension, available for Chrome and Chromium-compatible browsers. Recording takes place in the browser where the extension is installed. Playback — running the recorded test — occurs in TestInspector's Selenium-backed runner, which supports Chrome, Firefox, Edge, and Safari regardless of which browser was used for recording.

Does the extension capture network requests made during the recording?

The extension captures user interaction events — clicks, inputs, navigation, form submissions — not the underlying network requests those interactions trigger. Network-level HTTP request steps must be authored separately using TestInspector's HTTP request step type, either through the chat interface or the step editor. The browser extension and HTTP steps are complementary: record the UI flow with the extension and add HTTP assertions or API validation steps manually.

What happens if I record a workflow that includes a popup or modal dialog?

The extension captures interactions within popups and modal dialogs as standard steps, provided the elements are in the same browser tab. A click on a button inside a modal records as a click step with the modal button's selector. Interactions within browser-native dialogs (alert, confirm, prompt) may require explicit dialog-handling steps in the editor, since these are outside the normal DOM the extension observes.

Can I record a test that spans multiple tabs?

Multi-tab recording support depends on the extension version. The standard recording session captures interactions in the active tab; switching to a new tab during recording typically starts capturing in the new tab. Tests that genuinely span multiple tabs — for example, an OAuth flow that opens an authorization window — often require a combination of recorded steps and manually authored window-handling steps. Review the steps list after recording to confirm the capture correctly represents the multi-tab sequence before saving.

How does the extension handle iframes?

Interactions within iframes that are served from the same origin as the parent page are captured by the extension as normal steps. Cross-origin iframes — such as embedded payment widgets from a third-party provider — may not be captured, depending on browser security policies that restrict extension access across origin boundaries. For cross-origin iframe interactions, use HTTP request steps to test the underlying API endpoints directly rather than attempting to record interactions with the embedded widget.

Is the browser extension the same as the Selenium IDE format that TestInspector exports?

No. The browser extension records tests into TestInspector's internal step format, which is then runnable in TestInspector's hosted Selenium environment. The Selenium IDE (.side) export is a separate feature that converts a TestInspector test definition into the Selenium IDE format for use outside TestInspector. Recording with the extension and exporting to Selenium IDE are distinct operations that can be combined: record with the extension, refine in TestInspector, then export to .side if an external format is needed. See astaqc.com/test-inspector for the current list of supported export formats.