TestMu AI (Formerly LambdaTest) is the world's first full-stack AI Agentic Quality Engineering platform that empowers teams to test intelligently, smarter, and ship faster. Built for scale, it offers a full-stack testing cloud with 10K+ real devices and 3,000+ browsers. With AI-native test management, MCP servers, and agent-based automation, TestMu AI supports Selenium, Appium, Playwright, and all major frameworks.
With TestMu AI (Formerly LambdaTest), you can run Selenium Tests on HyperExecute Using TestMu AI (Formerly LambdaTest) across real browsers and operating systems.
- Sign up on TestMu AI (Formerly LambdaTest).
- Follow the TestMu AI Documentation for the full setup walkthrough.
- Node.js and npm (latest stable)
- A TestMu AI (Formerly LambdaTest) account with your username and access key
Before using HyperExecute, download the HyperExecute CLI for your OS and export the environment variables LT_USERNAME and LT_ACCESS_KEY from your TestMu AI (Formerly LambdaTest) Profile page.
HyperExecute CLI is the CLI for interacting and running the tests on the HyperExecute Grid. The CLI provides a host of other useful features that accelerate test execution. In order to trigger tests using the CLI, you need to download the HyperExecute CLI binary corresponding to the platform (or OS) from where the tests are triggered:
Also, it is recommended to download the binary in the project's parent directory. Shown below is the location from where you can download the HyperExecute CLI binary:
- Mac: https://downloads.lambdatest.com/hyperexecute/darwin/hyperexecute
- Linux: https://downloads.lambdatest.com/hyperexecute/linux/hyperexecute
- Windows: https://downloads.lambdatest.com/hyperexecute/windows/hyperexecute.exe
Before the tests are run, please set the environment variables LT_USERNAME & LT_ACCESS_KEY from the terminal. The account details are available on your TestMu AI (Formerly LambdaTest) Profile page.
For macOS:
export LT_USERNAME=LT_USERNAME
export LT_ACCESS_KEY=LT_ACCESS_KEYFor Linux:
export LT_USERNAME=LT_USERNAME
export LT_ACCESS_KEY=LT_ACCESS_KEYFor Windows:
set LT_USERNAME=LT_USERNAME
set LT_ACCESS_KEY=LT_ACCESS_KEYAuto-split execution mechanism lets you run tests at predefined concurrency and distribute the tests over the available infrastructure. Concurrency can be achieved at different levels - file, module, test suite, test, scenario, etc.
For more information about auto-split execution, check out the Auto-Split Getting Started Guide
Auto-split YAML file (HyperExecute-Yaml.hyperexecuteStatic.yaml) in the repo contains the following configuration:
globalTimeout: 90
testSuiteTimeout: 90
testSuiteStep: 90Global timeout, testSuite timeout, and testSuite timeout are set to 90 minutes. The runson key determines the platform (or operating system) on which the tests are executed. Here we have set the target OS as Windows.
runson: winAuto-split is set to true in the YAML file.
autosplit: trueretryOnFailure is set to true, instructing HyperExecute to retry failed command(s). The retry operation is carried out till the number of retries mentioned in maxRetries are exhausted or the command execution results in a Pass. In addition, the concurrency (i.e. number of parallel sessions) is set to 2.
retryOnFailure: true
runson: win
maxRetries: 2To leverage the advantage offered by Dependency Caching in HyperExecute, the integrity of package-lock.json is checked using the checksum functionality.
cacheKey: '{{ checksum "package-lock.json" }}'The caching advantage offered by NPM can be leveraged in HyperExecute, whereby the downloaded packages can be stored (or cached) in a secure server for future executions. The packages available in the cache will only be used if the checksum stage results in a Pass.
cacheDirectories:
- node_modulesThe testDiscovery directive contains the command that gives details of the mode of execution, along with detailing the command that is used for test execution. Here, we are fetching the list of Feature file scenario that would be further executed using the value passed in the testRunnerCommand
testDiscovery:
type: raw
mode: static
command: grep -nri '@uattest' features -ir --include=\*.feature | awk '{print$1}' | sed 's/:.*//'
testRunnerCommand: yarn run ltlocal $testRunning the above command on the terminal will give a list of Feature Scenario lines that are located in the Project folder:
Test Discovery Result: 2 features/duckDuckGo-search.feature features/getMethod.feature
The testRunnerCommand contains the command that is used for triggering the test. The output fetched from the testDiscoverer command acts as an input to the testRunner command.
testRunnerCommand: yarn run ltlocal $testThe mergeArtifacts directive (which is by default false) is set to true for merging the artifacts and combing artifacts generated under each task.
The uploadArtefacts directive informs HyperExecute to upload artifacts [files, reports, etc.] generated after task completion. In the example, path consists of a regex for parsing the directory (i.e. reports that contains the test reports).
mergeArtifacts: true
uploadArtefacts:
- name: Reports
path:
- reports\
HyperExecute also facilitates the provision to download the artifacts on your local machine. To download the artifacts, click on Artifacts button corresponding to the associated TestID.
The CLI option --config is used for providing the custom HyperExecute YAML file (i.e. HyperExecute-Yaml/.hyperexecuteStatic.yaml). Run the following command on the terminal to trigger the tests in JS files on the HyperExecute grid. The --download-artifacts option is used to inform HyperExecute to download the artifacts for the job.
./hyperexecute --config hyperexecute.yamlVisit HyperExecute Automation Dashboard to check the status of execution
Dependency caching is enabled in the YAML file to ensure that the package dependencies are not downloaded in subsequent runs. The first step is to set the Key used to cache directories.
cacheKey: '{{ checksum "yarn.lock" }}'Set the array of files & directories to be cached. In the example, all the packages will be cached in the CacheDir directory.
cacheDirectories:
- node_modulesSteps (or commands) that must run before the test execution are listed in the pre run step. In the example, the packages listed in requirements.txt are installed using the npm install command.
pre:
- npm installThe mergeArtifacts directive (which is by default false) is set to true for merging the artifacts and combing artifacts generated under each task.
The uploadArtefacts directive informs HyperExecute to upload artifacts [files, reports, etc.] generated after task completion. In the example, path consists of a regex for parsing the directory (i.e. reports that contains the test reports).
mergeArtifacts: true
uploadArtefacts:
- name: Reports
path:
- reports\HyperExecute also facilitates the provision to download the artifacts on your local machine. To download the artifacts, click on Artifacts button corresponding to the associated TestID.
In case you want to use any secret keys in the YAML file, the same can be set by clicking on the Secrets button the dashboard.
All you need to do is create an environment variable that uses the secret key:
env:
AccessKey: ${{.secrets.AccessKey}}HyperExecute lets you navigate from/to Test Logs in Automation Dashboard from/to HyperExecute Logs. You also get relevant get relevant Selenium test details like video, network log, commands, Exceptions & more in the Dashboard. Effortlessly navigate from the automation dashboard to HyperExecute logs (and vice-versa) to get more details of the test execution.
Connect with testers and developers in the TestMu AI Community. Ask questions, share what you are building, and discuss best practices in test automation and DevOps.
Earn free TestMu AI Certifications for testers, developers, and QA engineers. Validate your skills in Selenium, Cypress, Playwright, Appium, Espresso and more. Industry-recognized, shareable on LinkedIn, and built by practitioners, not marketers.
Learn modern testing through tutorials, guides, videos, and weekly updates:
On January 12, 2026, LambdaTest evolved to TestMu AI, the world's first fully autonomous Agentic AI Quality Engineering Platform.
Same team. Same infrastructure. Same customer accounts. All existing LambdaTest logins, scripts, capabilities, and integrations continue to work without change.
🔗 Find the new home for LambdaTest.
In 2017, we launched LambdaTest with a simple mission: make testing fast, reliable, and accessible. As LambdaTest grew, we expanded into Test Intelligence, Visual Regression Testing, Accessibility Testing, API Testing, and Performance Testing, covering the full depth of the testing lifecycle.
As software development entered the AI era, testing had to evolve, too. We rebuilt the architecture to be AI-native from the ground up, with autonomous agents that plan, author, execute, analyze, and optimize tests while keeping humans in the loop. The platform integrates with your repos, CI, IDEs, and terminals, continuously learning from every code change and development signal.
That evolution earned a new name: TestMu AI, built for an AI-first future of quality engineering. TestMu is not a new name for us. It is the name of our annual community conference, which has brought together 100,000+ quality engineers to discuss how AI would reshape testing, long before that became an industry norm.
What started as a high-performance cloud testing platform has transformed into an AI-native, multi-agent system powering a connected, end-to-end quality layer. That evolution defined a new identity: LambdaTest evolved into TestMu AI, built for an AI-first future of quality engineering.
Got a question? Email support@testmuai.com or chat with us 24x7 from our chat portal.