How to Run tests on LambdaTest (2026)

TL;DR

To run tests on LambdaTest, inject LT credentials as secrets, point your Selenium/Playwright/Cypress runner at LambdaTest with clear LT:Options, add a tunnel only for private apps, and grow from one smoke session to a scheduled CI matrix.

Key Takeaways

• Use LT_USERNAME and LT_ACCESS_KEY from a secret store in every environment.
• Centralize LT:Options for project, build, name, and debug artifacts.
• Prove one public-URL smoke before adding tunnels or large matrices.
• Prefer local PR gates and scheduled LambdaTest compatibility runs.
• Isolate data when raising parallel cloud sessions.
• Always surface session URLs and videos on failure.
• Govern minutes with justified browser matrices and fail-fast setup.

LambdaTest is a cloud cross-browser and real-device platform used heavily for Selenium, Playwright, Cypress, and Appium workloads. This guide shows how to run tests on LambdaTest end to end: credentials, capability design, Selenium and Playwright examples, tunnel setup for private apps, GitHub Actions wiring, smart parallelization, HyperExecute-style faster runners when relevant, and operational guardrails for 2026.

If you already understand remote WebDriver, LambdaTest will feel familiar: your test code stays local, browsers run in the cloud, and results appear in a web dashboard with video and logs. The skill is not clicking "start"; it is designing a reliable, secure, cost-aware pipeline.

TL;DR

Validate with one public URL test before you introduce tunnels, mobile devices, or maximum parallelism.

1. How to run tests on LambdaTest: platform mental model

LambdaTest Automate provides cloud browsers and devices accessible through standard automation protocols. You choose:

• desktop browser and version
• operating system
• optionally real mobile devices
• resolution and other session options
• debugging artifacts

Your framework (TestNG, JUnit, pytest, Playwright Test, WebdriverIO, Cypress) still owns assertions, fixtures, and reporting. LambdaTest owns the browser farm, streaming, and much of the session media.

How to run tests on LambdaTest well is therefore 30% vendor config and 70% ordinary good automation hygiene: isolation, waits, secrets, and CI design.

2. Create credentials and environment variables

From the LambdaTest dashboard, copy username and access key. Export them locally:

export LT_USERNAME="your_username"
export LT_ACCESS_KEY="your_access_key"
export LT_BUILD_NAME="local-$(date +%Y%m%d-%H%M)"

Never place keys in screenshots of docs that get committed. Prefer a password manager or direnv with a gitignored .envrc.

GitHub Actions secrets:

• LT_USERNAME
• LT_ACCESS_KEY

Optional variables:

• LT_BUILD_NAME derived from github.run_id
• APP_URL for the environment under test

3. Selenium hub URL and capability shape

A common hub pattern:

https://{LT_USERNAME}:{LT_ACCESS_KEY}@hub.lambdatest.com/wd/hub

Capabilities combine W3C browser fields with LambdaTest-specific options. Field names can vary slightly by client version; keep vendor options centralized in one factory.

Node.js WebDriverIO-style caps (conceptual):

// lambdatest.capabilities.js
exports.ltCaps = {
  browserName: "Chrome",
  browserVersion: "latest",
  "LT:Options": {
    platformName: "Windows 11",
    project: "QAJobFit",
    build: process.env.LT_BUILD_NAME || "local-dev",
    name: "checkout-smoke",
    w3c: true,
    plugin: "node_js-webdriverio",
    video: true,
    console: true,
    network: true,
  },
};

Python pytest example:

import os
import pytest
from selenium import webdriver

@pytest.fixture
def driver():
    user = os.environ["LT_USERNAME"]
    key = os.environ["LT_ACCESS_KEY"]
    options = webdriver.ChromeOptions()
    options.set_capability("browserName", "Chrome")
    options.set_capability("browserVersion", "latest")
    options.set_capability("LT:Options", {
        "platformName": "Windows 11",
        "project": "QAJobFit",
        "build": os.environ.get("LT_BUILD_NAME", "local-dev"),
        "name": "home-heading",
        "video": True,
        "visual": True,
        "network": True,
        "console": True,
    })
    url = f"https://{user}:{key}@hub.lambdatest.com/wd/hub"
    drv = webdriver.Remote(command_executor=url, options=options)
    yield drv
    drv.quit()

def test_home_heading(driver):
    driver.get(os.environ.get("APP_URL", "https://example.com"))
    assert driver.title

Centralize capability construction so every suite inherits naming and debug defaults.

4. How to run tests on LambdaTest with Playwright

Playwright projects can target LambdaTest's cloud browsers using the platform's Playwright support. Keep tests framework-native; swap connection details via environment flags.

// playwright.config.ts
import { defineConfig } from "@playwright/test";

const onLambdaTest = process.env.RUN_ON_LAMBDATEST === "1";

export default defineConfig({
  timeout: 90_000,
  retries: process.env.CI ? 1 : 0,
  use: {
    baseURL: process.env.APP_URL,
    trace: "on-first-retry",
    screenshot: "only-on-failure",
  },
  projects: [
    {
      name: onLambdaTest ? "lt-chrome" : "local-chrome",
      use: {
        browserName: "chromium",
        // Wire LambdaTest Playwright connection per current LT docs
        // using LT_USERNAME / LT_ACCESS_KEY from the environment.
      },
    },
  ],
});

Run:

RUN_ON_LAMBDATEST=1 LT_BUILD_NAME="pw-smoke-1" npx playwright test tests/smoke

Keep a local project always available. Developers should not need the cloud to refactor a locator.

5. Cypress on LambdaTest

Cypress support typically uses a LambdaTest Cypress CLI or npm package that uploads the project and runs it on cloud browsers. High-level flow:

1. Install the LambdaTest Cypress CLI dependency used by your org standard.
2. Provide username and access key.
3. Declare browser list and run settings in a config file.
4. Execute the CLI in CI.

Conceptual config sketch:

{
  "lambdatest_auth": {
    "username": "${LT_USERNAME}",
    "access_key": "${LT_ACCESS_KEY}"
  },
  "browsers": [
    {
      "browser": "Chrome",
      "platform": "Windows 11",
      "versions": ["latest"]
    }
  ],
  "run_settings": {
    "build_name": "cy-smoke",
    "parallels": 2,
    "specs": "./cypress/e2e/smoke/**/*.cy.js",
    "npm_dependencies": {
      "cypress": "13.15.0"
    }
  }
}

Pin Cypress and plugin versions. Cloud runners that float versions create "mystery" diffs.

6. Tunneling to local and private environments

LambdaTest provides a tunnel binary for private applications. Pattern:

./LT --user "$LT_USERNAME" --key "$LT_ACCESS_KEY" --tunnelName "ci-${GITHUB_RUN_ID}"

Then set tunnel-related capability flags so the session uses that tunnel name. Verify with a static page served on localhost before testing a full stack.

Operational tips:

• unique tunnel names per CI job
• health-check loop before starting tests
• always stop the tunnel in if: always() cleanup
• prefer publicly reachable ephemeral preview URLs when security policy allows, because tunnels add moving parts

7. Parallel execution and test isolation

Cloud minutes scale with session time times concurrency. To run tests on LambdaTest efficiently:

• enable framework parallelization (TestNG parallel, pytest-xdist, Playwright workers) within plan limits
• isolate users and data per worker
• avoid global mutable singletons
• shard long suites across jobs

strategy:
  fail-fast: false
  matrix:
    shard: [1, 2, 3]
steps:
  - run: npm run test:lt -- --shard=${{ matrix.shard }}/3
    env:
      LT_USERNAME: ${{ secrets.LT_USERNAME }}
      LT_ACCESS_KEY: ${{ secrets.LT_ACCESS_KEY }}
      LT_BUILD_NAME: gha-${{ github.run_id }}-shard-${{ matrix.shard }}

Do not raise parallels before tests are hermetic. Parallel flakes are more expensive in the cloud.

8. Marking status and capturing evidence

Update session status in teardown so dashboards match reality. Many WebDriver clients use execute hooks similar to:

const status = passed ? "passed" : "failed";
const reason = passed ? "ok" : String(errorMessage).slice(0, 255);
await browser.execute(
  `lambda-status=${status}`,
);
// Prefer the current LambdaTest-documented status API for your client.
// Also attach reason metadata when the API supports it.

Always retain:

• short failure reason
• screenshot on failure
• link to LambdaTest session in CI annotations

Teams lose hours when CI only says "exit code 1" without a session URL.

9. How to run tests on LambdaTest in GitHub Actions

name: lambdatest-nightly
on:
  schedule:
    - cron: "30 5 * * *"
  workflow_dispatch:

jobs:
  e2e:
    runs-on: ubuntu-latest
    timeout-minutes: 40
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: npm
      - run: npm ci
      - name: Smoke on LambdaTest
        env:
          LT_USERNAME: ${{ secrets.LT_USERNAME }}
          LT_ACCESS_KEY: ${{ secrets.LT_ACCESS_KEY }}
          LT_BUILD_NAME: nightly-${{ github.run_id }}
          APP_URL: ${{ vars.STAGING_URL }}
          RUN_ON_LAMBDATEST: "1"
        run: npm run test:lt:smoke
      - if: always()
        uses: actions/upload-artifact@v4
        with:
          name: lt-artifacts
          path: |
            test-results
            playwright-report
            cypress/videos
            cypress/screenshots

Pair this with a fast local PR workflow so developers are not blocked on cloud queues. General pipeline structure is covered in add CI to a test framework.

10. BrowserStack vs LambdaTest vs local (decision table)

Both cloud vendors solve similar problems. Pick based on pricing, device catalog, compliance, and existing skill, not blog hype. If you need the BrowserStack-specific path, see how to run tests on BrowserStack.

11. HyperExecute and "faster cloud CI" options

LambdaTest markets accelerated test execution environments (often discussed under HyperExecute) that focus on reducing orchestration overhead for large suites. When evaluating:

• measure end-to-end wall clock, not marketing claims
• confirm framework support for your stack
• check how artifacts and secrets are handled
• ensure flaky retries remain visible
• compare against simply cutting suite size and improving local parallelization

Buy speed only after removing waste. A cloud multiplier on a messy suite multiplies cost.

12. Governance, security, and compliance notes

• restrict who can read LT secrets
• redact tokens from HAR files before sharing
• understand data residency options for regulated apps
• avoid testing production with destructive flows on shared cloud browsers
• set retention expectations for videos that may contain PII
• document an offboarding step to rotate keys

If tests enter customer data, prefer synthetic accounts and masked datasets. Cloud recordings amplify privacy mistakes.

13. Troubleshooting playbook

Reproduce with parallels=1, a public sample page, and debug flags before blaming the vendor.

14. Practical rollout plan (two weeks)

Day 1-2: one Selenium or Playwright smoke on Chrome Windows against a public staging URL.

Day 3-4: add build naming, status marking, and artifact links in CI.

Day 5-6: add one Safari or Firefox combination that matches user analytics.

Day 7-8: introduce tunnel only if required; document start/stop.

Day 9-10: schedule nightly matrix; keep PR on local browsers.

Day 11-14: add flake monitoring and minute budgets; train the team on dashboard triage.

This sequence prevents "big bang cloud migration" pain.

15. Capability factory and environment profiles

Avoid scattering LT:Options across repos. Create one factory that accepts a profile name and test title:

# lt_factory.py
import os
from selenium import webdriver

PROFILES = {
    "chrome_win": {
        "browserName": "Chrome",
        "browserVersion": "latest",
        "LT:Options": {"platformName": "Windows 11"},
    },
    "firefox_win": {
        "browserName": "Firefox",
        "browserVersion": "latest",
        "LT:Options": {"platformName": "Windows 11"},
    },
    "safari_mac": {
        "browserName": "Safari",
        "browserVersion": "latest",
        "LT:Options": {"platformName": "macOS Sonoma"},
    },
}

def create_driver(profile: str, test_name: str):
    user = os.environ["LT_USERNAME"]
    key = os.environ["LT_ACCESS_KEY"]
    base = PROFILES[profile]
    options = webdriver.ChromeOptions() if base["browserName"] == "Chrome" else webdriver.FirefoxOptions()
    # For multi-browser factories, select Options class by browserName.
    options.set_capability("browserName", base["browserName"])
    options.set_capability("browserVersion", base["browserVersion"])
    lt = dict(base["LT:Options"])
    lt.update({
        "project": os.environ.get("LT_PROJECT", "QAJobFit"),
        "build": os.environ.get("LT_BUILD_NAME", "local-dev"),
        "name": test_name,
        "video": True,
        "network": True,
        "console": True,
    })
    options.set_capability("LT:Options", lt)
    hub = f"https://{user}:{key}@hub.lambdatest.com/wd/hub"
    return webdriver.Remote(command_executor=hub, options=options)

Product teams call create_driver("safari_mac", "checkout totals") and never touch auth.

16. Designing smoke vs deep compatibility suites

How to run tests on LambdaTest without drowning in minutes requires suite tiers:

Map each UI test to a tier. Most tests never need the release matrix. Critical money paths and auth might.

Tagging example with Playwright:

test.describe("checkout", { tag: "@nightly" }, () => {
  test("tax calculation updates", async ({ page }) => {
    /* ... */
  });
});

CI job selects tags. Cloud jobs select cloud projects. Local jobs ignore cloud tags.

17. Network, geolocation, and media edge cases

Cloud platforms sometimes expose extras such as geolocation, custom network conditions, or timezone overrides. Use them sparingly and document defaults.

Good uses:

• verify locale currency formatting under a specific timezone
• validate a degraded network message once, not on every test
• confirm permission prompts on mobile web where relevant

Bad uses:

• randomizing network conditions on the entire suite (manufactures flakes)
• testing pixel-perfect layout under throttling meant for performance labs

Keep performance testing in dedicated tools; keep functional compatibility on LambdaTest.

18. Failure taxonomy for cloud UI tests

When a LambdaTest job fails, classify before changing code:

1. Setup: bad secrets, wrong APP_URL, tunnel down.
2. Product: assertion correctly caught a bug.
3. Test: brittle locator, race, shared data.
4. Environment: staging outage, flag misconfig.
5. Platform: queue timeout, browser crash farm-side.

Only categories 2-3 should produce product or test PRs. Category 1 should fail with a clear precheck message before sessions open:

#!/usr/bin/env bash
set -euo pipefail
: "${LT_USERNAME:?LT_USERNAME missing}"
: "${LT_ACCESS_KEY:?LT_ACCESS_KEY missing}"
: "${APP_URL:?APP_URL missing}"
curl -fsS "$APP_URL/health" >/dev/null
echo "precheck ok"

Prechecks save real money.

19. Team onboarding script

New engineers should complete this in under half a day:

1. Obtain secrets via the team vault, not Slack DMs.
2. Run local smoke without cloud.
3. Run one LambdaTest Chrome session against staging.
4. Force a failure and find the video in the dashboard.
5. Read the matrix policy doc (PR vs nightly).
6. Open a tiny PR adding a test under the correct tag.

If onboarding requires a hero session with a senior engineer every time, your factory and docs are incomplete. Fix the system.

20. Sample monorepo notes

In monorepos, bind LambdaTest projects to package names (web-app, admin-ui) so billing and dashboards map to teams. Do not dump every package into one generic build name. Use:

LT_PROJECT="@acme/web"
LT_BUILD_NAME="${LT_PROJECT}-${GITHUB_RUN_ID}"

Each package keeps its own smoke entry script. The root workflow can matrix over packages that opted into cloud compatibility.

21. Comparing CLI-driven vs raw WebDriver flows

Pick one primary path per framework to avoid dual maintenance. Document the exception path for experiments.

22. Final acceptance criteria for production use

You can claim how to run tests on LambdaTest is production-ready when:

1. A scheduled workflow has run green for two weeks with stable minutes.
2. Developers open session videos without asking QA.
3. Secrets rotation was rehearsed once.
4. Tunnel runbooks exist only if tunnels are required.
5. Flake rate on cloud is measured separately from local.
6. The browser list is reviewed quarterly against analytics.

Until then, treat the integration as beta and keep release gates on faster local signal plus a thin cloud smoke.

23. Concrete WebDriverIO service sketch

WebdriverIO users often configure LambdaTest via environment and capabilities in wdio.conf.ts:

// wdio.conf.ts (excerpt)
export const config = {
  user: process.env.LT_USERNAME,
  key: process.env.LT_ACCESS_KEY,
  hostname: "hub.lambdatest.com",
  path: "/wd/hub",
  port: 443,
  protocol: "https",
  maxInstances: 3,
  capabilities: [
    {
      browserName: "Chrome",
      browserVersion: "latest",
      "LT:Options": {
        platformName: "Windows 11",
        project: "QAJobFit",
        build: process.env.LT_BUILD_NAME || "local",
        name: "wdio-smoke",
        video: true,
        network: true,
        console: true,
      },
    },
  ],
  specs: ["./test/specs/smoke/**/*.ts"],
  framework: "mocha",
  reporters: ["spec"],
};

Run with:

LT_BUILD_NAME="wdio-${GITHUB_RUN_ID:-local}" npx wdio run ./wdio.conf.ts

Keep local wdio.local.conf.ts without cloud host settings so offline work remains possible. Dual configs beat a single config full of conditionals that nobody trusts.

24. What "done" looks like for stakeholders

Engineering managers care about risk reduction per dollar. Show them:

• which user browsers are covered and why
• wall-clock of nightly cloud suite
• monthly minute trend
• escaped defects that cloud caught (and those it missed)

If cloud catches nothing unique for a quarter, shrink the matrix. How to run tests on LambdaTest includes knowing when to run fewer tests.

When stakeholders ask for more devices, answer with analytics share, prior escaped defects, and minute impact. That conversation keeps the program honest and sustainable over multiple release cycles.

Interview Questions and Answers

Q: How do you run tests on LambdaTest from CI?

Inject LT_USERNAME and LT_ACCESS_KEY from secrets, set build metadata from the run id, execute the test command that points at the LambdaTest hub or CLI, upload artifacts, and publish session links. Prefer scheduled wide matrices.

Q: What is the hub URL pattern?

A remote WebDriver URL that embeds credentials and targets hub.lambdatest.com with /wd/hub, paired with W3C capabilities and LT:Options for platform and debug settings.

Q: How do private applications work?

Start the LambdaTest tunnel with a unique name, enable tunnel options in capabilities, and verify connectivity with a trivial page before the full suite.

Q: How is Cypress execution different from Selenium on LambdaTest?

Cypress often uses a vendor CLI that packages specs and runs them remotely, while Selenium typically drives a remote WebDriver session directly from your process. Both still need secrets, naming, and CI artifact discipline.

Q: How do you keep cloud runs affordable?

Small PR coverage, hermetic parallel tests, fail-fast setup, and nightly full matrices. Review minute usage by project.

Q: What do you log on failure?

Assertion message, browser/OS, build name, session URL, screenshot, and relevant console/network logs. That set is enough for most remote triage.

Q: Local versus cloud: how do you split?

Local or container browsers for developer feedback and PR gates; LambdaTest for compatibility coverage and real devices that local CI cannot provide.

Common Mistakes

• Hardcoding access keys in capability JSON committed to git.
• Running the full device catalog on every push.
• Skipping tunnel health checks.
• Using one shared customer account for parallel suites.
• Ignoring browser-specific failures as flake.
• No session naming, making dashboard search useless.
• Not failing fast when APP_URL is wrong.
• Storing videos of real PII without retention policy.
• Changing three variables at once when debugging.
• Migrating 100% of tests to cloud on week one.

Conclusion

How to run tests on LambdaTest is a pipeline design problem: secure credentials, stable capabilities, isolated data, deliberate matrices, and evidence-rich failures. Start with one green cloud smoke, automate it on a schedule, then expand browsers only when user risk justifies the minutes.

When you are ready to systematize matrices across vendors and local engines, read how to set up cross browser testing. For flake control once remote latency enters the picture, use how to reduce flaky tests in a CI pipeline.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• How to Run tests on BrowserStack (2026)
• How to Run tests in headed mode in Cypress (2026)
• How to Run tests in headed mode in Playwright (2026)
• How to Run tests in headed mode in Selenium (2026)
• How to Add accessibility checks to CI (2026)
• How to Add CI to a test framework (2026)