ScreenshotNeo

BlogHow-to

How to Use Selenium IDE for Browser Test Automation

Record a browser workflow, refine it into a reusable test, and choose the right path for playback, CI, Grid execution, or code export.

By the ScreenshotNeo team4 October 202610 min read

Selenium IDE records browser actions as Selenium commands and replays them as tests. To get started, create a project, set its base URL, record a user workflow, inspect and refine the captured steps, then save the project as a .side file and play the test or suite.

Selenium IDE’s packaging has changed: older instructions describe a browser extension, while the v4 project wiki says the latest version is no longer a web extension and the current repository describes an Electron application. Check the current Selenium IDE project and release information for the installation path and capabilities that match your version. Selenium’s overview lists Chrome, Firefox, and Edge, but some detailed setup and runner pages are older. Selenium IDE overview · v4 project wiki

1. Install and open Selenium IDE

  1. Use the current project release or browser-store path appropriate for your browser and Selenium IDE version. The official Getting Started guide has browser-extension-era instructions, so verify them against current release information.
  2. Launch Selenium IDE. If you installed a browser extension and cannot see its icon, check that the extension is enabled and that the browser has not hidden it in the toolbar.
  3. Choose the option to create a new project or start recording. The wording and launch flow can vary by release.

A project is the container for tests and suites. Its base URL is shared by its tests and can be changed later. The Getting Started guide documents that workflow, though its page was last updated in 2019.

2. Record your first browser test

  1. Name the project. Choose a name that identifies the application or test area.
  2. Set the base URL. Use the application’s origin or starting address. A project’s tests use this shared base URL, and you can override it later in runner workflows.
  3. Start recording. Selenium IDE opens or manages a browser window for the recording.
  4. Perform one user journey. Navigate and interact as a user would: for example, open a page, fill a form, submit it, and reach the expected result.
  5. Stop recording and inspect the commands. Edit or remove noisy steps, correct locators, and add commands manually where that makes the test clearer.
  6. Save the project. Save changes in the IDE. A project is stored in a .side file.

Recording is a quick way to create a starting point, not a guarantee that every generated locator will remain stable as the application changes. Review the recorded commands and make the intent of important steps explicit. Selenium’s documentation describes commands and parameters as based on each element’s context; it does not promise that recorded locators are robust across application changes.

Keep the test focused

  • Record a single outcome at a time, such as completing a sign-in flow or adding an item to a cart.
  • Use meaningful test names so test filtering later is useful.
  • Delete accidental clicks, exploratory navigation, and steps that depend on unrelated page state.
  • When an important condition is not obvious from the recording, add or refine commands in the IDE and replay the test.
  • Keep environment-specific addresses out of assumptions where possible; use the project base URL or the runner’s documented base-URL override.

3. Organize, save, and replay tests

Create tests in the Tests view and group related tests into suites. A new project starts with a Default Suite containing the first test, according to the Getting Started guide. Suites are useful for a smoke-check group or a coherent user journey.

  1. Open the project’s Tests view and create or select a test.
  2. Use the suite controls to group tests that should be run together.
  3. Save the project to its .side file after changing tests, suites, or commands.
  4. Select a test or suite and use the play control to run it. The guide says Selenium IDE reuses the existing recording window when it is open; otherwise, it opens a new window.
  5. Review the run and adjust commands when the recorded workflow no longer matches the application.

For an initial test, in-IDE playback is the fastest feedback loop. When the project needs repeatable command-line execution, browser configuration, reports, or remote browsers, consider the runner or code export.

4. Choose how to execute the project

Route Best fit What to plan for
IDE playback Authoring, debugging, and quick checks on a test or suite. Runs through the browser window managed by the IDE; useful for interactive feedback.
Command-line runner Repeatable runs, test-name filters, alternate base URLs, browser capabilities, and result files. Requires the runner plus a local browser/driver setup or remote Grid. The detailed runner guide is dated, so verify current prerequisites and configuration against current project documentation.
Code export Adapting a recorded flow into an existing WebDriver codebase and test framework. Generated code needs review and maintenance. Confirm that the current IDE release supports the desired export target.

5. Run a .side project from the command line

The Selenium IDE command-line runner guide documents invoking selenium-side-runner with a .side project, selecting browser capabilities, and connecting to Selenium Grid. Its instructions were last updated in 2019. Treat the examples below as the shape of the workflow, then consult current release documentation for installation commands, Node requirements, driver setup, and option names before configuring a machine or CI job.

# Run a saved IDE project with the runner
selenium-side-runner path/to/project.side

Runner configurations can select browser capabilities and remote Grid execution. The guide also describes workers, test-name filtering, base-URL overrides, proxy options, and Jest JSON or JUnit XML result output. It says suites run in parallel by default while tests within a suite run sequentially unless suite parallelization is enabled. Verify the behavior and exact flags for your installed runner version before depending on them in CI.

Local browser or Selenium Grid?

  • Local browser: use it when the machine running the runner can manage the browser and its driver. This keeps the first setup straightforward but ties execution to that machine’s installed browser environment.
  • Grid: use remote execution when browsers run on a separate Selenium Grid and you need to manage browser execution there. Configure the runner with the Grid endpoint and desired capabilities using the syntax supported by your runner version.
  • Multiple combinations: choose local workers or Grid capacity based on how many browser and platform combinations your team needs to manage. Parallelism can reduce elapsed time, but it also increases resource use and can expose tests that share mutable state.

Make command-line runs repeatable

  1. Keep the .side file with the project’s version-controlled test assets.
  2. Choose a test or suite naming scheme that supports filtering the intended CI subset, such as smoke checks.
  3. Pass the target environment’s base URL through the runner’s documented override rather than editing the project for each environment.
  4. Choose a result format consumed by your CI system, such as the documented JUnit XML or Jest JSON output, and verify the current runner’s flag syntax.
  5. Start with conservative parallelism. Increase workers only after confirming tests do not rely on shared accounts, shared records, or ordering.
  6. Pin and document the runner, browser, and driver versions used by your team. The old runner guide lists dated Node prerequisites; do not treat those as current requirements.

6. Export a test to WebDriver code

To export, right-click a test or suite, choose Export, select a target, and save the generated code, as described in Selenium IDE’s Code Export documentation. The documentation lists C# NUnit, Java JUnit, JavaScript Mocha, and Python pytest as export targets. It also describes an optional origin-tracing setting that adds comments mapping generated code to the IDE step. Because the page includes legacy framework and dependency examples, check the installed IDE’s current export choices and use current dependency instructions.

Review exported code before adopting it. Confirm the selectors and assertions match the test’s intent, replace environment-specific values, and fit the code into your project’s existing setup and cleanup conventions. Export is a bridge into a coded suite, not a guarantee that generated code is production-ready.

7. Browser support and version caveats

Selenium’s overview lists Chrome, Firefox, and Microsoft Edge. Selenium IDE v4 packaging differs from older extension-centric setup pages: the maintainers’ wiki says the latest version is no longer a web extension, and the current repository describes an Electron application. Check the current release path for your browser and installed version rather than assuming an older extension tutorial applies unchanged.

The v4 wiki also notes that local record and playback cannot properly handle browser-level features such as alerts or cookie clearing. Treat that as a specific caveat documented for v4, not as a complete feature matrix for every later release. If a test depends on browser-level behavior, confirm support for your installed version and consider whether a coded WebDriver test better expresses the requirement.

8. Common problems and fixes

Symptom Likely cause What to do
Selenium IDE icon is missing The browser extension is disabled, hidden, or the installed version uses a different launch method. Check the browser’s extension controls for an extension install; for v4 or newer, consult the current project release instructions.
Recorded test fails on replay The page changed, a captured locator no longer matches, or a step depends on timing or state not present on replay. Inspect the failing command and page state, update the locator or sequence, and replay from a clean starting state.
Test works interactively but fails in the runner The runner may use a different browser, base URL, environment, or configuration than the IDE session. Compare browser capabilities and target URL, confirm the runner’s current setup, and reproduce with the same environment settings.
Runner cannot start a browser Browser/driver setup, capabilities, or runner prerequisites do not match the installed versions. Check current Selenium IDE runner documentation and the browser/driver compatibility requirements for the chosen execution environment. Do not rely on the old guide’s version numbers.
Remote Grid session does not start The Grid endpoint is unreachable or the requested capabilities are unavailable. Verify endpoint reachability and capability names against the Grid and runner versions in use, then try a capability combination the Grid provides.
Tests pass alone but fail in a parallel suite Tests may share accounts, data, or ordering assumptions. Isolate test data and accounts, remove ordering dependencies, or reduce parallel execution for the affected suite using supported runner settings.
Expected alert or cookie-clearing behavior is not captured The v4 wiki documents limits for browser-level features during local record and playback. Confirm current-version behavior and use an approach that explicitly supports the required browser-level operation.
Export menu or framework target differs from a tutorial Export support and menus can vary by IDE release; the detailed export page has legacy examples. Check the installed version’s export choices and current framework documentation before adding dependencies.

9. Performance, reliability, and cost

Performance: IDE playback is convenient for authoring but is interactive. The runner supports workers and parallel suite execution in the documented workflow; parallelism can shorten overall runs when tests are independent, while increasing browser and machine resource use. Measure in your own CI environment and avoid sharing mutable test state.

Reliability: A recorded test is only as reliable as its locators, starting conditions, and assumptions about application state. Keep tests focused, review generated commands, and replay after application changes. For CI, make the browser, runner, environment URL, and result format explicit, and verify behavior against the current versions because the detailed runner guide is old.

Cost: Selenium IDE is a software workflow based on Selenium components; the research sources establish no specific paid product as necessary. Local execution uses the resources of the machine running the browser. Remote Grid capacity may have separate infrastructure or provider costs; verify any provider’s current pricing and terms directly.

10. When screenshots are part of the workflow

Selenium IDE is for browser test automation. If a workflow also needs to capture website screenshots for documentation, review, or an AI agent, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It is separate from Selenium IDE and does not replace browser test assertions or test execution.

Or skip the browser setup

For a screenshot, make one GET request. The example uses Stripe as the target; replace it with the page you are authorized to capture. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before the shot; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. Its MCP server offers take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

FAQ

Does Selenium IDE require programming?

You can record and replay a basic workflow without writing a test program. Editing commands, using the runner, and maintaining exported code can require more technical setup.

Can I run a Selenium IDE test in another browser?

The Selenium overview lists Chrome, Firefox, and Edge. The exact setup depends on the current IDE release and whether you run through the IDE, a local runner, or Grid.

Is a recorded test ready for CI as-is?

Not necessarily. Review its steps and locators, then configure the runner, browser environment, target URL, and result output for your current versions.

Should I export or keep the test in a .side file?

Keep it in the IDE when the project format and runner meet your needs. Export when your team wants to adapt the flow into an existing WebDriver codebase, and review the generated code and current target support.

Sources and version notes

Detailed setup, runner, and export pages include legacy-era guidance. Confirm installation, prerequisites, flags, and export targets with the current release before adopting them in a maintained automation pipeline.