Recording
Record browser interactions automatically with intelligent selector generation. QA Studio captures your clicks, text input, selections, and navigations as test steps in real-time via WebSocket streaming.
How Recording Works
The recording feature launches a real Playwright browser instance on the server and establishes a WebSocket connection between the browser and the QA Studio dashboard. As you interact with the web page in the recording browser, events are captured by injected scripts and streamed back to the dashboard in real-time.
The architecture works as follows:
- The server launches a Playwright browser (non-headless, so you can see and interact with it)
- JavaScript event listeners are injected into every page the browser navigates to
- User interactions (clicks, typing, selections) trigger events that are captured by the injected scripts
- Events are sent over a WebSocket connection to the server, which processes them into step definitions
- Steps are streamed to the dashboard in real-time via the WebSocket, appearing instantly in the test builder's steps list
Starting a Recording
To begin a recording session:
Open the Recorder
In the test builder, click the Record button in the top toolbar. This opens the RecorderBar component at the top of the builder.
Enter a Starting URL
Type the URL of the page you want to start recording from into the URL input field. This can be any publicly accessible URL or a local development server (e.g., http://localhost:3000).
Click Start
Click the Start button. QA Studio launches a browser window and navigates to your URL. A goto step is automatically added as the first recorded step. The recorder bar shows a red recording indicator while the session is active.
Interact with the Page
Use the browser window normally. Click buttons, fill in forms, select dropdown options, check checkboxes, and navigate between pages. Each interaction is captured and appears as a new step in the test builder.
What Gets Captured
The recorder captures the following types of browser interactions and converts them into test steps:
| Interaction | Generated Step | Details |
|---|---|---|
| Mouse clicks | click |
Captures the element selector using the 7-tier priority system. Clicks on links, buttons, and any other elements are recorded. |
| Text input | fill |
Captures text typed into input fields, textareas, and contenteditable elements. Input is debounced by 800ms to coalesce rapid keystrokes into a single fill step rather than recording each individual keystroke. |
| Dropdown selection | select |
Captures the selected option value when a <select> element changes. |
| Checkbox toggles | check / uncheck |
Captures checkbox state changes. Generates a check step when checked and uncheck when unchecked. |
| Page navigations | goto |
When the browser navigates to a new URL (via link clicks, form submissions, or JavaScript redirects), an automatic goto step is inserted to capture the new URL. |
Text input is debounced by 800 milliseconds. This means QA Studio waits for you to stop typing for 800ms before generating a single fill step with the complete text value. This prevents generating dozens of individual keystroke steps and produces cleaner, more maintainable tests.
Selector Generation Priority
When the recorder captures an interaction with an element, it generates a selector using a 7-tier priority system. The recorder tries each strategy in order and uses the first one that produces a unique, stable selector:
| Priority | Strategy | Selector Mode | Example Output |
|---|---|---|---|
| 1 (highest) | data-testid attribute |
testid | submit-form |
| 2 | id attribute |
css | #login-button |
| 3 | ARIA role + accessible name | role | button:Sign In |
| 4 | Placeholder text | placeholder | Enter your email |
| 5 | Label text | label | Email Address |
| 6 | Visible text content | text | Submit Order |
| 7 (lowest) | CSS path | css | div.form > button.primary |
The priority system favors selectors that are resilient to UI changes. A data-testid attribute will never change due to styling or text updates, making it the most stable option. CSS paths are used as a last resort because they are the most fragile and can break when the page layout changes.
If you control the source code of the application you are testing, add data-testid attributes to interactive elements (buttons, inputs, links, form controls). This gives the recorder the most stable possible selectors, and your tests will be resilient to CSS refactors, text content changes, and layout modifications.
Stopping and Reviewing
When you are done interacting with the page:
- Click the Stop button in the recorder bar. This closes the recording browser and ends the WebSocket connection.
- All captured steps are now visible in the test builder's steps list (center panel).
- Review each step and its generated selector. You can click any step to edit its properties in the step editor (right panel).
- Reorder steps by dragging them, delete unnecessary steps, or modify selectors and values as needed.
- Add additional steps manually if the recorder did not capture everything you need (e.g., assertions, waits, screenshots).
The recorded steps are fully editable after the session ends. They behave exactly like manually-created steps and support all the same features including drag-and-drop reordering, environment variable substitution, and selector mode changes.
Post-Recording Refinement
After stopping a recording, it is good practice to:
- Add assertion steps — The recorder captures interactions but does not generate assertions. Add
assertsteps to verify expected outcomes (e.g., assert that a success message is visible, the URL changed, or a specific element contains the expected text). - Add wait steps — If your application has animations or async loading, add explicit
waitsteps where needed to ensure elements are ready before interacting with them. - Review selectors — Check that the auto-generated selectors are targeting the intended elements. If a CSS path was generated (priority 7), consider switching to a more stable selector mode.
- Add screenshot steps — Insert
screenshotsteps at key points for visual regression testing. - Remove redundant steps — The recorder may capture extra clicks or navigations that are not essential to the test flow. Delete any unnecessary steps.
Recording Best Practices
Use data-testid attributes on your application's interactive elements. This produces the most stable, resilient selectors that do not break when CSS classes, text content, or page structure changes.
Review generated selectors after each recording session. The auto-generated selectors are a starting point, not the final word. Adjust selector modes and values to match your team's testing conventions.
Recording works with any website. You can record interactions on third-party sites, local development servers, staging environments, or production URLs. The recorder does not require any special setup on the target application (though data-testid attributes help if you can add them).
Keep recordings focused. Record one user flow at a time rather than trying to capture an entire application walkthrough. Shorter, focused tests are easier to maintain and debug.
Pause between actions if needed. The 800ms debounce on text input means you should finish typing before clicking elsewhere to ensure the full text is captured.
Limitations
The recording feature has a few limitations to be aware of:
- Hover actions — Hover interactions are not recorded because distinguishing intentional hovers from incidental mouse movement is unreliable. Add
hoversteps manually if needed. - Keyboard shortcuts — Complex keyboard combinations (Ctrl+C, Ctrl+V, etc.) are not captured. Use
presssteps manually for keyboard actions. - File uploads — File upload dialogs are not recorded. Handle file uploads with manual steps.
- iframes — Interactions inside iframes may not be captured depending on the iframe's origin and security policy.
- Shadow DOM — Elements inside closed shadow DOM trees may not be reachable by the injected event listeners.