Migrating
Move an existing BrowserStack or LambdaTest suite to TestKase by changing a single URL — what changes, and how capabilities map.
Migrating from BrowserStack / LambdaTest
If your suite already runs on BrowserStack or LambdaTest, migration is a one-URL change. TestKase speaks the same W3C WebDriver and Playwright protocols, so your test code, assertions, and framework stay exactly as they are.
What changes
Only two things:
- The hub URL — swap the vendor's WebDriver endpoint for the TestKase endpoint.
- The vendor capability block — rename
bstack:options/LT:Optionstotestkase:options.
Everything else — your capabilities' W3C shape, your worker/parallelism config, your CI steps — is untouched.
The URL swap
- const hub = "https://USER:KEY@hub-cloud.browserstack.com/wd/hub";
+ const hub = "https://<email>:<accessKey>@hub.testkase.com/wd/hub";
const capabilities = {
browserName: "chrome",
- "bstack:options": { os: "OS X", osVersion: "Sequoia" },
+ "testkase:options": { username: "<email>", accessKey: "<accessKey>" },
};Point your CI at the new endpoint and re-run the pipeline — no new SDK, no test rewrites, no new assertions.
For the Selenium URL, URL-encode the @ in your email as %40 in the userinfo section, or your binding may drop the credentials.
Capability mapping
| Concept | BrowserStack | LambdaTest | TestKase |
|---|---|---|---|
| Vendor block | bstack:options | LT:Options | testkase:options |
| Browser | browserName | browserName | browserName (same W3C key) |
| Version | browserVersion | browserVersion | browserVersion — supports latest, latest-N, or exact major |
| Platform | os / osVersion | platform | platformName: macOS 15 / macOS 26 |
| Build grouping | buildName | build | testkase:options.build |
| Session name | sessionName | name | testkase:options.name |
| Auth | userName / accessKey | user / accessKey | URL basic-auth, or testkase:options.username / accessKey |
Per-test hooks
The LambdaTest-style lambda-name / lambda-status executor hooks map directly — just rename the prefix to testkase:
driver.executeScript("testkase-name=Search renders results");
driver.executeScript("testkase-status=passed");These follow the LambdaTest pattern verbatim, so existing suites migrate without touching the surrounding logic. See Selenium → per-test metadata.
Playwright migration
For Playwright, the cleanest migration is the @testkase/playwright-reporter wrapper CLI — install it, add a testkase.yml, and run via npx testkase-playwright test. Your test files stay 100% native Playwright, the same way the BrowserStack and LambdaTest node SDKs work.
Things to know before you switch
TestKase's testkase:options is intentionally a subset of the vendor blocks (build, name, username, accessKey, tags, plus the capture flags). The dozens of proxy/geo/advanced flags those vendors ship are not all mirrored. Two current gaps: there is no local-testing tunnel yet (your test target must be a publicly reachable URL), and native mobile app automation (Appium) is coming soon — Automate is browser automation today.