saucelabs-automate

Author and run E2E tests on Sauce Labs - cloud grid for cross-browser + real-device testing with W3C WebDriver, Cypress, Playwright, and Appium support. Covers SAUCE_USERNAME + SAUCE_ACCESS_KEY auth, regional hub URLs (us-west-1 / us-east-4 / eu-central-1), W3C capabilities, sauce:options dict (build, name, screenResolution, tunnelName), Sauce Connect Proxy for internal-environment testing. Use for cross-browser regression with Sauce Labs as the cloud grid; complements BrowserStack + LambdaTest as alternative providers.

Install with skills.sh (any agent)

npx skills add testland/qa --skill saucelabs-automate

View source

saucelabs-automate

Overview

Sauce Labs is one of the original cloud-grid providers (alongside BrowserStack + LambdaTest). It exposes a W3C-compliant WebDriver endpoint covering desktop + mobile browser combinations, with strong Cypress / Playwright / Appium support.

Per docs.saucelabs.com/dev/test-configuration-options (opens in new window).

Composes with browser-matrix-strategy-reference (in the qa-compatibility plugin) for matrix planning.

When to use

Cross-browser regression with Sauce Labs as the chosen grid provider.
Real-device testing via Sauce's mobile cloud.
Internal-network apps via Sauce Connect Proxy.
Comparison testing - Sauce + BrowserStack run the same suite to catch grid-specific flakes.

Authoring

Authentication

Per Sauce docs:

export SAUCE_USERNAME="oauth-...-..."
export SAUCE_ACCESS_KEY="<access-key-from-user-settings>"

Hub URLs (regional)

US-West:  https://ondemand.us-west-1.saucelabs.com:443/wd/hub
US-East:  https://ondemand.us-east-4.saucelabs.com:443/wd/hub
EU-Central: https://ondemand.eu-central-1.saucelabs.com:443/wd/hub

Pick the region closest to your CI runner for lower latency.

Capabilities (W3C)

Per Sauce config docs:

{
  "browserName": "chrome",
  "browserVersion": "latest",
  "platformName": "Windows 11",
  "sauce:options": {
    "build": "PR-1234",
    "name": "Login flow on Chrome Windows",
    "username": "$SAUCE_USERNAME",
    "accessKey": "$SAUCE_ACCESS_KEY",
    "screenResolution": "1920x1080",
    "tunnelName": "my-internal-tunnel",
    "extendedDebugging": true,
    "capturePerformance": true,
    "recordVideo": true,
    "recordScreenshots": true,
    "tags": ["smoke", "e2e", "auth"]
  }
}

Standard W3C: browserName, browserVersion, platformName.

sauce:options carries Sauce-specific:

Option	Purpose
`username` / `accessKey`	Credentials (can also be in URL)
`build`	Group sessions by CI build
`name`	Session label in dashboard
`screenResolution`	Default 1024×768; common: 1920×1080
`tunnelName`	Sauce Connect Proxy tunnel reference (preferred over deprecated `tunnelIdentifier`)
`extendedDebugging`	Enable HAR + console + Selenium logs
`capturePerformance`	Browser performance metrics
`recordVideo` / `recordScreenshots`	Session capture
`tags`	Free-form tags for filtering

Per Sauce docs the browserVersion accepts "latest", "latest-1", etc. - version-relative pinning works across release cycles.

Python example

import os
from selenium import webdriver

options = webdriver.FirefoxOptions()
options.browser_version = "latest"
options.platform_name = "Windows 11"

sauce_options = {
    "build": os.environ.get("BUILD_TAG", "local"),
    "name": "Checkout flow Firefox",
    "username": os.environ["SAUCE_USERNAME"],
    "accessKey": os.environ["SAUCE_ACCESS_KEY"],
    "screenResolution": "1920x1080",
    "extendedDebugging": True,
}

# Set vendor caps on the Options object BEFORE creating the driver. In
# Selenium 4 W3C mode driver.capabilities is a read-only result dict, so
# assigning to it after Remote() is a no-op and sauce:options never applies
# (per the [Selenium options] docs).
options.set_capability("sauce:options", sauce_options)

driver = webdriver.Remote(
    command_executor="https://ondemand.us-west-1.saucelabs.com:443/wd/hub",
    options=options,
)

driver.get("https://example.com")
# test...
driver.quit()

Running

Report session status

# Sauce-specific JS executor to mark pass/fail
sauce_user = os.environ["SAUCE_USERNAME"]
sauce_key = os.environ["SAUCE_ACCESS_KEY"]
driver.execute_script(
    f"sauce:job-result={'passed' if not failed else 'failed'}"
)

Or via REST API: PUT /rest/v1/{username}/jobs/{session_id}.

Sauce Connect Proxy

For internal-network apps:

# Download Sauce Connect 5 from saucelabs.com
./sc \
  --username $SAUCE_USERNAME \
  --access-key $SAUCE_ACCESS_KEY \
  --tunnel-name "my-internal-tunnel" \
  --region us-west-1

Then set sauce:options.tunnelName: "my-internal-tunnel" in capabilities. Tunnel cleans up on Ctrl+C.

For ephemeral CI: spawn → wait-for-ready → run tests → terminate.

Parallel session limits

Sauce plans cap concurrent (parallel) sessions by tier; throttle to stay under your account's limit via ThreadPoolExecutor or the CI-matrix max-parallel key.

Parsing results

Per Sauce docs, session reports include:

Session video (always - recordVideo: true default)
Network HAR (if extendedDebugging: true)
Browser console logs
Selenium logs
Screenshot per command (if recordScreenshots)
Performance metrics (if capturePerformance)

Retrieve via REST:

curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" \
  "https://api.us-west-1.saucelabs.com/rest/v1/$SAUCE_USERNAME/jobs/<session-id>"

CI integration

on: pull_request
jobs:
  sauce:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        browser:
          - { name: chrome, version: latest, platform: "Windows 11" }
          - { name: safari, version: "17", platform: "macOS 14" }
          - { name: edge, version: latest, platform: "Windows 11" }
    steps:
      - uses: actions/checkout@v6
      - name: Run on Sauce Labs
        env:
          SAUCE_USERNAME: ${{ secrets.SAUCE_USERNAME }}
          SAUCE_ACCESS_KEY: ${{ secrets.SAUCE_ACCESS_KEY }}
          SAUCE_BROWSER: ${{ matrix.browser.name }}
          SAUCE_VERSION: ${{ matrix.browser.version }}
          SAUCE_PLATFORM: ${{ matrix.browser.platform }}
          BUILD_TAG: pr-${{ github.event.pull_request.number }}
        run: pytest tests/e2e/ --sauce

Anti-patterns

Anti-pattern	Why it fails	Fix
Hardcoded region	Latency from CI to grid varies; cross-region adds 100ms+	Match region to CI runner location
Missing `build` field	Dashboard unsearchable	Always set to CI build / PR identifier
`tunnelIdentifier` (deprecated)	Newer SC versions emit warnings	Use `tunnelName`
Polling for tunnel ready without timeout	Test suite hangs if SC never connects	Bounded wait + fail
Mixed regions in one test run	Increases flake	Pick one region per run
Not setting session status	Pass/fail metrics inaccurate	Always update status before quit
`recordVideo: false` to "save money"	Failed-session debugging hard	Keep `recordVideo: true` for failed sessions at minimum

Limitations

Regional differences. Each region has its own device matrix + availability; some browsers / versions are region-specific.
Sauce Connect setup overhead. Internal-environment testing needs SC tunnel; setup adds 10-30s to test-start.
Plan limits + queue overflow. Sessions queue when parallel limit reached.
Video / artifact retention. Free / lower-tier plans have short retention (often 7 days); paid plans extend.

References

Sauce Labs test config options - docs.saucelabs.com/dev/test-configuration-options (opens in new window).
Sauce Connect 5 docs - docs.saucelabs.com/secure-connections/sauce-connect-5 (opens in new window).
Sauce Labs REST API - docs.saucelabs.com/dev/api.
W3C WebDriver specification - w3.org/TR/webdriver2/ (opens in new window).
Selenium options (opens in new window) - Selenium 4 browser-options classes; set_capability for vendor-prefixed caps before driver creation.
Composes: browser-matrix-strategy-reference.
Sibling skills: browserstack-automate, lambdatest-automate, selenium-grid-4-runner.

Related skills

browserstack-automate

Author and run E2E tests on BrowserStack Automate - cloud grid covering 3000+ real device + browser combinations. Covers BROWSERSTACK_USERNAME + ACCESS_KEY auth, hub URL https://hub-cloud.browserstack.com/wd/hub, W3C capabilities + bstack:options (projectName, buildName, sessionName), BrowserStackLocal for testing against localhost / internal environments, parallel session limits, and CI integration. Use for cross-browser regression on real devices + browsers - distinct from running a single test framework locally, and from a matrix runner limited to the browser engines bundled on the local machine.

cypress-testing

Authors and improves Cypress E2E tests - installs Cypress, configures `cypress.config.ts`, authors `cy.*` command chains, refactors existing specs (`cy.wait(ms)` sleeps into assertions, repeated flows into `cy.session` custom commands), and debugs with the time-travel GUI; Cypress Cloud for parallel runs and recording. Use for both greenfield test authoring and improving hand-written specs already in the codebase. For automated refactor of raw Cypress Studio recordings specifically, use a dedicated codegen-review pass.

lambdatest-automate

Author and run E2E tests on LambdaTest - cloud grid for cross-browser + real-device testing with W3C WebDriver, Cypress, Playwright, and Appium support. Covers LT_USERNAME + LT_ACCESS_KEY auth, hub URL hub.lambdatest.com/wd/hub, W3C capabilities + LT:Options dict (build, name, project, smartUI, network, console, video, tunnel), LambdaTest Tunnel for internal apps. Use for cross-browser regression with LambdaTest as the cloud grid; complements BrowserStack + Sauce Labs.

playwright-testing

Authors and remediates Playwright E2E tests across Chromium, Firefox, WebKit - `npm init playwright@latest` scaffolding, `playwright.config.ts` browser projects, accessibility-first locators (`getByRole`/`getByLabelText`) to replace brittle CSS selectors, web-first assertions to eliminate `waitForTimeout` flakiness, Page Object pattern, trace viewer debugging, sharded parallel execution with merged HTML reporting, and GitHub Actions CI integration. Use for new test authoring, flakiness remediation, and CI setup; for reviewing codegen output specifically, use a dedicated codegen-review pass.

puppeteer-testing

Authors browser automation scripts using Puppeteer - Chrome / Chromium-only headless / headed automation, Page object via `page.*` API, network interception, PDF generation, screenshot capture, scraping. Distinct from Playwright (Puppeteer's older sibling, Chrome-only) - use Puppeteer for Chrome-only browser automation tasks (scraping, generating PDFs from HTML, screenshot pipelines) where Playwright's multi-browser support is unneeded overhead. Use when a project already depends on `puppeteer` / `puppeteer-core`, or when a Chrome-only script must emit PDFs, screenshots, or scraped data rather than assert on a page.

selenium-testing

Authors Selenium WebDriver tests in any of its 6+ supported languages (Java, Python, JavaScript, C#, Ruby, Kotlin, PHP) - picks the appropriate language binding, configures WebDriver per browser, uses `By.*` locators with the team's accessibility-first preference where supported, runs locally + via Selenium Grid for distributed execution, parses results to JUnit XML. Use for legacy Selenium-locked stacks; new projects pick Playwright or Cypress.

testcafe-testing

Authors TestCafe E2E tests - `npm install testcafe`, fixture/test syntax, `Selector` API for queries, automatic-waits, no WebDriver required (TestCafe injects scripts via a proxy), supports any browser including remote / cloud farms. Use when the team prefers a no-WebDriver architecture and one of TestCafe's specific features (e.g., role-based auth) matters.

web-e2e-overview

Teaches web end-to-end testing from first principles: what browser-driven E2E covers and how it differs from unit and integration tests, a decision table for choosing between Playwright, Cypress, Selenium WebDriver, WebdriverIO, Puppeteer, TestCafe and the BrowserStack / Sauce Labs / LambdaTest cloud grids based on files already present in the repo, install and first-run commands for each, and the flakiness traps (fixed sleeps, CSS and XPath selectors, state shared between tests) that sink new suites. Use when a web application has no E2E coverage yet, when picking or replacing an E2E framework, or when a first browser test needs to go green end to end.

webdriverio-testing

Authors WebdriverIO E2E tests - `npm init wdio@latest` scaffolding, services architecture (sauce, browserstack, appium, devtools), reporters (spec, allure, junit), built-in Mocha/Jasmine/Cucumber framework integrations. WebdriverIO sits between Selenium (W3C protocol) and Playwright (modern API) - Selenium-protocol-compatible with rich plugin ecosystem. Use when the team needs WebDriver protocol + service-based device-farm integration.