How a Retail Enterprise 4x’d Device Coverage Without Buying Devices

How a Retail Enterprise Scaled Device Coverage 4x

Summarize this blog post with:

A large US retailer operated 800+ stores alongside an eCommerce site and native Android and iOS applications.

Its quality engineering team tested customer journeys across digital and physical channels, from product discovery and cart creation to store pickup, POS payment, loyalty updates, and returns.

The retailer had already invested in specialized equipment for store validation. Its test environment included POS terminals, payment peripherals, barcode scanners, receipt printers, rugged handhelds, and store tablets configured for its apps and workflows.

Several critical tests depended on that equipment. At the same time, its internal lab couldn’t efficiently provide the wider browser, mobile device, and operating-system coverage required for consumer-facing releases.

TestGrid gave the retailer a hybrid test environment that combined client-controlled store hardware with dedicated hosted browser and mobile resources. Let’s see how.

Results at a Glance

  • 39% shorter regression window: The agreed omnichannel regression scope decreased from approximately 36 hours to 22 hours.
  • 4x broader browser and mobile coverage: The priority release matrix expanded from 24 to 96 browser, device, and operating-system combinations.
  • 64% fewer tests delayed by device contention: Scheduled runs affected by unavailable hardware decreased from approximately 14% to 5%.
  • 58% less device administration: Weekly effort spent coordinating device access and availability decreased from approximately 26 hours to 11 hours.

The Internal Test Lab Reached Its Limit

The retailer’s QA organization included 46 engineers working across three locations in the United States and India.

The team supported releases across the eCommerce site, mobile applications, store applications, and the services connecting orders, payments, loyalty accounts, and inventory.

Its internal device lab had grown around store-specific requirements. POS terminals, scanners, payment equipment, printers, and store tablets reproduced workflows that depended on physical hardware, local configuration, and retailer-specific applications.

A typical regression cycle could start with a customer creating an order through the mobile application. The test might then modify fulfillment details through the website, retrieve the order through a store application, complete payment at a POS terminal, print a receipt, verify the loyalty update, and process a return.

Test accounts, order identifiers, backend services, and controlled test data connected these stages. The store hardware supported these workflows well. Browser and mobile coverage presented a different problem.

The retailer maintained a limited collection of Android phones, iPhones, tablets, and browser machines. Product teams wanted greater coverage across current and previous operating-system versions, manufacturers, screen sizes, and browsers.

Expanding the internal lab for every requested combination would have increased device purchasing, patching, connectivity, maintenance, and replacement work. Access also became difficult during release regression.

Several engineers could need the same phone, POS terminal, or store tablet during the same testing window. Teams coordinated reservations through calendars and messages, which made availability difficult to assess and restricted parallel execution.

Expanding the Physical Lab Would Have Added More Administration

The retailer had already automated a significant portion of its regression coverage.

Selenium and Cypress handled web workflows such as search, product pages, cart updates, checkout, account management, and order history. Appium covered priority Android and iOS journeys.

Store validation used customer-specific automation where practical, together with controlled manual checks for interactions involving POS terminals, payment devices, scanners, printers, and other peripherals.

The retailer needed to retain this environment because several tests depended on its existing hardware configuration.

Purchasing enough consumer devices to support the wider mobile and browser matrix would have solved only the capacity problem. The QA organization would also have taken on additional device administration.

A hybrid infrastructure model gave the team another option. Specialized equipment could remain under the retailer’s control, while TestGrid provided dedicated capacity for browser and mobile testing.

We Combined Client-Controlled Hardware With Dedicated Test Infrastructure

We integrated TestGrid with the retailer’s existing test environment, keeping store-dependent tests on client-controlled hardware while extending browser and mobile execution to dedicated TestGrid resources:

Expanded the priority test matrix from 24 to 96 combinations

The retailer created a priority matrix based on customer usage, operating-system adoption, browser share, device risk, and recent production defects.

TestGrid added real-device and browser capacity across Chrome, Safari, Firefox, Edge, Android, and iOS. The priority matrix increased from 24 to 96 browser, device, and operating-system combinations.

Coverage was applied according to risk. Purchasing, authentication, account, checkout, and order-management journeys ran across a broader set of environments, while lower-risk tests used smaller representative groups.

This gave the team wider compatibility coverage without running every test against every possible combination.

Ran existing automation across the right test environments

The retailer continued using its Selenium, Cypress, and Appium suites.

Selenium and Cypress handled browser workflows. Appium covered selected Android and iOS journeys. Store-specific automation continued against the physical equipment required for those scenarios.

For cross-channel tests, the team passed state between stages through controlled customer accounts, order IDs, transaction references, and backend test data.

An Appium test could create an order through the mobile application. A Cypress test could update the fulfillment details through the website. Store validation could then retrieve the same order and verify pickup, payment, receipt generation, loyalty processing, or return behavior.

Each test stage ran against the environment required for that part of the retail workflow.

Reduced device access delays

Shared hardware had previously required regular coordination between testers, QA leads, and lab administrators.

Reservation workflows gave distributed engineers clearer access to devices with limited availability. Testers could confirm resource availability before starting a test session instead of resolving conflicts after execution was ready to begin.

This reduced waiting time around scarce store hardware and supported more parallel activity during regression.

Gave Engineers More Context for Failure Analysis

TestGrid provided logs, screenshots, video records, and test reports for supported executions.

When a browser or mobile test failed, engineers could review the application state, device or browser combination, execution output, and related evidence during triage.

That helped the team determine whether a failure came from the application, automation, environment, or device-specific behavior before assigning it for investigation.

We Kept the Existing Store Hardware in the Test Process

The retailer retained its configured POS terminals, payment peripherals, scanners, printers, store tablets, and handheld devices.

This preserved established store configurations, peripheral connections, test data dependencies, and retailer-specific applications.

The implementation therefore didn’t require a broad replacement of equipment that was already serving a valid testing requirement.

Distributed QA engineers also gained a more consistent way to access supported client-controlled resources. Device reservation reduced the need to coordinate every session through separate calendars and messages.

“Our biggest constraint was getting the right test environment at the right time. We already had POS systems, scanners, payment equipment, and automation that we needed to keep. TestGrid gave our teams access to that environment while adding the browser and mobile capacity we were missing. The same regression scope that took about 36 hours was completed in roughly 22, with far less coordination around device access.”
– Director of Quality Engineering, US Retail Enterprise

Test Web, Mobile, and In-Store Retail Workflows With TestGrid

Retail applications often depend on both consumer devices and specialized store equipment. We support cloud, on-premise, private dedicated, and hybrid test infrastructure for teams testing across web, mobile, and enterprise environments.

Existing Selenium, Appium, and Cypress automation can run against supported TestGrid browser and real-device infrastructure, with device reservation, parallel execution, reporting, and execution evidence available through the platform.

Request a TestGrid trial to evaluate hybrid testing for web, mobile, POS, and other in-store retail workflows.