Introduction
One of the world’s largest automakers and a prominent name on Forbes Global 500 list operates across four distinct vehicle brands, offering customers a full range of cars, trucks, and luxury vehicles. Beyond the physical product, the organisation has been accelerating its push into software-driven experiences, integrating services such as third-party applications and personalised in-vehicle features directly into the consumer journey, with the goal of delivering a seamless end-to-end experience from the website to the dealership.
The marketing and services team is responsible for the digital products that power that experience, including 3D visualisation tools that allow customers to configure and personalise their vehicles online. Delivering those products reliably, at pace, and with full visibility across a growing QA organisation required more than their legacy test management tooling could provide.
By adopting BrowserStack Test Management alongside Automate, Live, Percy, and Test Reporting and Analytics, the team replaced a fragmented, script-heavy process with a unified, AI-assisted QA platform now used by more than 20 teams across the organisation.
The challenge
A legacy tool that created friction at every stage of the testing lifecycle
Before BrowserStack, the team managed their test cases, test plans, and reporting through Azure DevOps (ADO). As the QA organisation matured and delivery expectations grew, ADO’s limitations became a persistent drain on team productivity, release confidence, and cross-functional visibility.
1. Custom scripts that broke constantly: Integrating test automation results with ADO required custom-written scripts. These scripts failed regularly due to proxy issues and maintenance gaps, forcing QA engineers to pause regression cycles to debug tooling rather than test products. What should have been a three to four day regression window regularly stretched to five or six days as a direct result.
2. A steep and slow learning curve: Onboarding new QA engineers onto ADO required significant training investment. The lack of intuitiveness meant that time which should have gone toward testing was spent learning how to operate the tool and maintain its custom integrations.
3. No unified view across the QA ecosystem: With bug reporting, automation execution, and test management sitting in separate tools, the team had no single place to see the full picture. Consolidating data across these systems added overhead and introduced the risk of gaps in coverage going unnoticed.
4. Test coverage falling through the cracks: Because automation results could not be reliably reported back to ADO, many test cases that should have been executed automatically had to be run manually instead. This consumed significantly more time and resource, pulled engineers away from higher-value work, and threatened sign-off timelines on releases with tight deadlines.
5. No metrics to share with leadership: With no reliable reporting infrastructure in place, the QA team had no quantitative data to bring to senior stakeholders. Upper management had no visibility into test coverage, pass or fail rates, or the split between manual and automated testing, making it difficult to build the case for investment or demonstrate the value of quality engineering.
6. Inability to differentiate test case types at scale: As the team grew, the need to tag and filter test cases by type, whether functional, security, or UI-focused, became critical. ADO made this difficult to manage consistently, creating risk around whether the right tests were being prioritised when time was limited.
“We spent a lot of time on training and writing custom scripts just to generate reports. These scripts tended to fail often due to proxy issues or scripts that needed to be updated and maintained, and this slowed down our regression process considerably.” – Quality Engineer
