What’s New at TestGrid: Broader Coverage, Faster Execution, Tighter Control

Testing gets complicated at the edges. Builds change mid-cycle, teams queue for a limited device pool, camera- and audio-dependent workflows resist reliable automation, and a single failure can absorb hours of engineering time before anyone knows what caused it.

The challenge is not only running more tests: Capgemini’s 2025–26 World Quality Report found that 60% of organizations struggle with secure, scalable test data.

This latest round of TestGrid updates spans six areas: camera and audio input on remote devices, execution distribution across your device pool, test maintenance, credential handling, asset management, and failure investigation.

Here’s what’s changed and where it helps.

1. Camera and Microphone Input on Remote Devices

Some test scenarios depend on inputs that are easy to provide when a device is in hand, but harder to reproduce when that device is hosted remotely. TestGrid’s latest capabilities extend remote testing to workflows that require camera and audio interaction:

a. Single and multiple media injection

Many mobile workflows depend on the device camera for critical use cases such as cheque deposits, KYC verification, QR/barcode payments, ID capture, and face verification.

TestGrid now lets you inject an uploaded image, GIF, or supported video into the camera-processing flow of a remote device during manual sessions and automated runs.

Multiple media files can also be injected sequentially within the same test. A cheque-deposit flow may need the front and back of a cheque; a KYC flow may require several identity documents; proof-of-liveness testing may depend on GIF or video input.

Once the application is prepared for the first injection, additional images, GIFs, or videos can be introduced into the same running session without repeatedly reinstalling the application. This brings previously manual, camera-dependent scenarios into repeatable E2E testing.

b. Audio In and Audio Out

TestGrid now supports both audio input and output when testing on remotely hosted real devices.

While Audio Out routes sound produced by the remote device to your local machine, Audio In works in the other direction, sending audio from your laptop microphone to the remote device. You can also use prerecorded audio as the input.

That opens up remote testing for voice and video calls, voice commands, voicemail configuration, media playback, and applications that respond to spoken or prerecorded audio. The capability can also be incorporated into automated workflows.

Also Read: Audio Testing for Chatbots

Execution Distribution Across the Device Pool

Large test suites create another challenge: deciding what runs where, how available devices are used, and what happens when demand exceeds capacity. Three TestGrid capabilities address different parts of that problem:

a. Quantum Grid

Running tests from your own automation framework normally means handling a fair amount of orchestration yourself, from device selection and availability checks to queue management and parallel-execution logic.

TestGrid’s Quantum Grid provides a common execution layer that identifies suitable available devices and distributes sessions automatically.

Sessions can run in parallel when capacity is available and queue when matching devices are already occupied. Allocation is dynamic, so available devices that meet the test requirements can be used without coordinating each execution individually.

Executions can also be prioritized when certain test runs need to move ahead of others. Quantum Grid can reuse builds already available through centralized App Management.

The result is less manual device coordination, better use of available infrastructure, and faster execution of larger test workloads.

b. Scriptless Smart Single and Multiple Runs

These features distribute test workloads differently depending on whether your priority is speed or device coverage. With a Single Run, the selected suite executes once, but its test cases are distributed across available devices to get the result faster.

If you have 100 test cases and 10 available devices, for example, TestGrid can spread those cases across the pool instead of running all 100 sequentially through a single device.

A Multiple Run optimizes for coverage instead. The selected suite runs across each required device or device category – for example, both an iPhone 16 and an iPhone 17.

Where multiple identical devices are available, TestGrid can still distribute the workload while ensuring each required model receives complete coverage.

c. Emulator and simulator automation support

Emulators and simulators can now participate in Scriptless and local automation executions. That gives you another option for high-volume smoke testing during development, when every execution may not require physical hardware.

Virtual and real devices can also be used alongside one another as testing progresses.

Real devices remain the preferred option for accurate production-level validation, while emulator and simulator support gives teams additional execution capacity.

3. Test Maintenance

Automation shouldn’t require another layer of repetitive work simply to accommodate different environments, changing data, or reusable workflows. TestGrid has expanded several capabilities aimed at reducing how often the underlying test suite needs to be edited:

a. Runtime arguments

With this feature, you can supply or change values when a test runs without modifying the underlying test.

That could mean changing the environment or URL, using different credentials, passing environment-specific values or JSON-based data, or using flags to determine which actions and validations should execute.

The same automation can therefore run against staging and later production, or execute with different users and data combinations, without maintaining several near-identical versions of the same test.

One test can support more scenarios, reducing duplication and ongoing maintenance.

b. Function parameterization

This feature lets the same reusable function accept different values each time it is used. Take an enrollment workflow. The automation itself may remain identical while values such as Student ID, Class, or Section change for each execution.

Instead of recreating the same sequence for every student or any other user, record, or scenario, you can reuse one function and simply change the inputs. That reduces duplicated test logic and makes larger automation suites easier to maintain.

c. Test data parameterization

The test may stay the same even when the data behind it changes constantly. With test data parameterization, test cases can retrieve data from external sources such as JSON files, APIs, and databases instead of relying entirely on values embedded directly inside the test case.

The automation continues working with the linked source, allowing frequently changing customer accounts, employee records, student information, or transactional data to be used without repeatedly editing the test itself. This makes data-driven automation easier to scale and maintain.

d. New codeless keywords

TestGrid has also expanded its Scriptless keywords, allowing more sophisticated operations to remain within codeless automation rather than requiring custom scripts. The new capabilities include API calls, JSON and XML payload handling, page-load measurement, date and string utilities, and working with information returned by APIs.

e. Adaptive AI auto-healing

Application changes and flaky behavior are common reasons automated tests fail. A new field gets added, an existing flow changes, or an element appears somewhere the original test wasn’t expecting it.

Adaptive AI auto-healing is designed to help the test adapt to these changes during execution instead of simply stopping.

When the system detects an unexpected change, it can identify what has changed, determine how the test should respond, and continue the workflow.

It then shows the temporary adjustment to the user, who can review it and decide whether that change should become permanent for future executions.

Take a registration test built around four fields: Name, Email, Address, and Phone Number.

If the application later adds a Customer ID field, adaptive auto-healing can recognize the new field, determine an appropriate value, add the required step temporarily, and allow the rest of the test to continue instead of failing at that point.

The capability can also adapt to certain changes within an existing workflow, not just newly added fields.

Adaptive AI auto-healing is currently being rolled out in stages. It’s important to note that its effectiveness can also vary depending on how clearly the application’s elements and underlying properties can be identified.

Also Explore: Self-Healing Agent

4. Credential Handling

Sensitive credentials introduce their own requirements into automation. Two TestGrid capabilities help keep those values protected while still making them available when a test needs them:

a. Secure blocks

This feature protects sensitive steps within Scriptless automation. Values such as passwords can be masked, and screenshots can be restricted for the protected steps. That allows sensitive actions to remain part of an automated workflow without unnecessarily exposing the credentials or information involved.

b. HashiCorp Vault support for scriptless

Enterprises often don’t want passwords, API keys, tokens, or other secrets stored directly inside test cases, scripts, or automation files.

TestGrid’s HashiCorp Vault support for Scriptless allows tests to use secrets stored in Vault without exposing the sensitive value directly inside the test case. The credential remains managed in Vault while the automation retrieves what it needs during execution.

5. Build and Test Asset Management

As testing grows across teams and projects, managing the assets surrounding automation becomes just as important as creating the tests themselves.

a. Centralized app management

TestGrid’s App Management provides a central repository for APK/AAB, IPA/APP, and simulator-compatible builds. You can upload a build once and reuse it across Real Devices and Emulator/Simulator Cloud, Scriptless Automation, Quantum Grid, and CI/CD executions.

Rather than navigating a rigid application-project-version structure, you can search directly for the build you need. Devices can be tagged so a build can be installed across a selected device group, while role-based permissions control access to specific applications and directories.

Builds can also be uploaded through CI/CD APIs so teams work with the same approved application version. The result is fewer repeated uploads, less build-version confusion, and a more consistent testing process across teams.

b. Codeless project and test asset management

Larger codeless implementations can quickly accumulate projects, versions, test suites, and test cases. TestGrid now provides additional ways to organize and reuse those assets.

Projects can be arranged into directories with access controlled through role-based permissions. They can also be backed up and restored, while complete versions can be copied or cloned when existing automation needs to be reused.

That makes it easier to manage larger automation libraries without rebuilding complex tests or manually copying individual cases.

c. GitLab integration

TestGrid’s GitLab integration connects TestGrid versions with GitLab repositories, bringing version-controlled workflows into the way teams manage changes to their test automation projects.

Changes can be worked on as drafts before they are committed, giving users an opportunity to review what has changed and discard work they don’t want to retain. Once ready, the approved changes can be committed to the linked GitLab repository.

This brings clearer version control and traceability to test changes while allowing teams to manage them within an existing GitLab workflow.

6. Reporting and Failure Investigation

A failed test is only useful if you can quickly understand what happened and reproduce it.

TestGrid’s latest reporting improvements include HTML execution reports, AI-generated summaries for a faster view of what happened during a run, and downloadable PDF reports for results that need to be shared or retained.

When a test fails, you can also rerun it immediately, including on the same device used for the original execution. That makes it easier to reproduce device-specific issues and investigate failures without rebuilding the complete execution setup first.

Scale Testing Without Adding More Manual Work

These updates address different sources of friction across the testing process, from workflows that have traditionally been difficult to automate remotely to execution bottlenecks, test maintenance, credential security, asset management, and failure investigation.

The common thread is reducing the manual work surrounding automation itself, so teams can extend coverage and scale execution without making their testing environment increasingly difficult to manage.

Want to see how these capabilities behave against your own applications and device requirements? Request a free TestGrid trial to walk through the platform with our team.