Elsevier slashes test execution time by 70% and ships faster with BrowserStack

As a global leader in information and analytics, Elsevier helps researchers and healthcare professionals advance science and improve health outcomes for the benefit of society. Growing from its roots in publishing, Elsevier offers knowledge and valuable analytics that help users make breakthroughs and drive societal progress. Among its many product lines, Elsevier builds and maintains a portfolio of clinical care research products used by clinicians and nursing staff across hospitals and medical institutions worldwide. These are analytics-driven applications that give healthcare professionals immediate, accurate answers to clinical queries, and they need to work reliably and without interruption regardless of the device, browser, or geography a user is accessing them from.

Abhishek Das, Engineering Manager – Quality at Elsevier, leads quality engineering across these clinical care research products, overseeing a diverse global team responsible for ensuring every release meets the highest standards of reliability, safety, and performance.

With teams distributed globally and a user base spanning multiple continents, Elsevier needed a testing infrastructure that could match the scale and diversity of its real-world usage. By adopting BrowserStack’s App Automate, Automate, and Test Reporting and Analytics across more than 30 products, Elsevier improved release velocity by 40%, reduced test execution time by 70%, and brought post-execution failure analysis down from over 2 hours to just 15 minutes.

Elsevier’s clinical products are accessed by users across different countries, institutions, and network environments, each bringing their own combination of device, browser, and operating system. The QA team was responsible for ensuring consistent behaviour across all of these combinations before every release. Without a scalable, centralised infrastructure to support that, the team faced growing pressure on both quality and delivery timelines.

1. Cross-device and cross-browser fragmentation at scale: Elsevier’s products needed to work on MacBooks and Windows machines, on Internet Explorer and the latest versions of Chrome, on Android smartphones and iOS devices, and even on older institutional devices that had not been updated in years. The range of required test combinations was too broad for any internal device lab to cover comprehensively.

2. Maintaining a Selenium grid was a constant overhead: Setting up, maintaining, and scaling an internal Selenium grid consumed significant engineering time and still only covered a limited set of device and browser combinations. Every new device or browser version potentially required additional infrastructure work.

3. Release cycles stretching to nearly a week: Because automation only covered a fraction of the required combinations, manual testing had to fill the gaps. Getting a feature tested thoroughly across five browsers and multiple device types could take five to six days before a release could go out with confidence. This directly impacted delivery velocity.

4. QA teams diverted from high-value work: The combination of manual device testing and infrastructure management meant QA engineers were spending the majority of their time on repetitive, low-signal work instead of exploratory testing, functional coverage improvements, or investigation of complex issues.

5. Geographically diverse users with different device habits: Elsevier’s user base spans multiple regions, and device preferences vary significantly by market. Testing only on the devices prevalent in one geography risked missing real-world failures for users in others. For example, Android usage patterns in certain markets differ significantly from Apple-heavy markets, and ensuring the right device coverage for each was difficult without access to a broad real device cloud.

6. Reproducing and communicating failures was time-consuming: When issues were found, it was often difficult to replicate them on demand or to give developers enough context to act quickly. QA engineers had to manually reconstruct the failure scenario, which was both time-consuming and sometimes impossible when the issue was environment-specific or intermittent.

After evaluating multiple cloud testing vendors, Elsevier selected BrowserStack and migrated more than 30 products to the platform. Three factors were decisive: the breadth and depth of the real device and browser combination library, the richness of the Test Reporting and Analytics dashboard, and the quality of onboarding support that made migration at scale achievable.

1. App Automate and Automate for parallel execution across real devices: With more than 30 automation threads running in parallel, Elsevier could now execute tests across Android, iOS, Chrome, Firefox, Safari, and multiple legacy browser versions at the same time, rather than sequentially. What previously demanded days of sequential manual and automated testing was compressed into a single, time-boxed parallel run. The ability to configure everything through a single configuration file meant that QA engineers no longer needed to spend time on infrastructure setup at all.

2. Access to 3,500 plus real device and OS combinations: BrowserStack’s device cloud gave Elsevier on-demand access to the full landscape of real devices, including the latest flagship phones and tablets from Apple, Samsung, Google Pixel, Vivo, and others, as well as older models still in active use by hospital and institutional users. It also provided access to legacy browser versions, allowing the team to test against the Chrome or Firefox version a specific customer base was still running, regardless of whether the internal team had upgraded.

3. App Live for real-device manual and exploratory validation: For scenarios where developers or QAs needed to reproduce an issue on a specific device, validate a fix interactively, or explore how the application behaved under real conditions, App Live provided instant access to real devices without any hardware dependency. This became a key tool for both QA and developer workflows, enabling anyone in the team to test on any device at any time.

4. Test Reporting and Analytics as the central intelligence layer: The dashboard aggregated execution results across all products in one place, presenting failure patterns, error frequency, unique versus repeated failures, and trend data across the last several builds. Rather than manually reviewing CI/CD pipeline logs to understand what had failed and whether it was a new issue or a recurring one, the team could see it clearly in a structured, visual format within minutes of a run completing. The platform also highlighted which part of a video recording contained the failure, with network logs and HAR files attached, so that investigation could begin immediately without any additional manual effort.

5. BrowserStack MCP for AI-assisted failure analysis: Elsevier integrated BrowserStack with their internal AI tool using BrowserStack MCP, allowing them to fetch execution logs, failure data, error types, and network patterns directly into their internal LLM-based investigation workflows. This reduced the time spent on post-execution failure analysis from one to two hours per cycle down to 15 minutes. Critical failures were categorised, error types identified, and patterns flagged automatically, leaving the team to focus on interpretation and action rather than data gathering.

6. Self-healing locators for test stability: Because Elsevier’s products share components managed by a central design team rather than individual squads, UI attributes could change without any direct input from the QA team maintaining the automation scripts. BrowserStack’s self-healing capability detected when an element’s XPath or CSS attribute had changed and suggested the correct updated locator, eliminating the need for QAs to manually hunt through scripts to identify what had broken. This was particularly valuable when a shared component appeared across multiple products simultaneously.

7. Smooth onboarding across 30 plus products: Migrating a single product to a new cloud testing platform is a manageable exercise. Migrating more than 30 is a significant undertaking. BrowserStack’s support team assisted with configuration files across every product in scope, helped with IP whitelisting requirements, and provided documentation and on-demand support throughout. The result was a migration that, while large in scale, was described as easy and seamless.

With BrowserStack providing the infrastructure layer for device and browser testing across the full Elsevier product portfolio, the quality engineering team was able to redirect its time and effort toward higher-value activities. The results were measurable across release velocity, execution time, failure analysis speed, and team productivity.

1. 40% improvement in release velocity. By eliminating the infrastructure bottleneck and enabling parallel execution across all required device and browser combinations, Elsevier significantly reduced the end-to-end time from feature completion to production release. Release regression, which previously required up to a week of sequential testing, could now be completed in a fraction of that time, allowing teams to ship with confidence at a much faster cadence.

2. 70% reduction in test execution time. Running more than 30 parallel automation threads through BrowserStack, across multiple device types and browser versions simultaneously, compressed what previously took two to three hours on internal CI/CD pipelines into a significantly shorter window. Threads ran across Chrome, Firefox, Safari, and other combinations concurrently, meaning the holistic report was ready in the time it previously took to run a single browser pass.

3. Failure analysis cut from 2 hours to 15 minutes. Using BrowserStack MCP to connect execution data to internal AI-assisted investigation workflows, the team reduced post-run analysis time dramatically. Previously, analysing failures required manually checking reports, replicating issues, and correlating data across tools. Now, critical failures are categorised, error types identified, and network log patterns surfaced automatically, with the team stepping in only to validate findings and direct fixes.

4. 30+ products successfully migrated. BrowserStack is now the unified testing infrastructure across Elsevier’s full clinical product portfolio, not just a tool used by one team. The consistency this brings to reporting, test execution standards, and failure investigation across different squads and product lines is itself a quality improvement.

5. Pattern recognition across builds enabled earlier production intervention. The Test Reporting and Analytics dashboard gave Elsevier visibility into failure trends across multiple recent builds, enabling the team to identify recurring patterns before they reached production. In one instance, a recurring subset of test case failures was traced back to a specific package migration, a pattern that would have been significantly harder to identify from raw CI/CD logs. This kind of cross-build pattern matching now runs as a standard part of the pre-production review.

6. Faster developer and QA collaboration through shareable session links. With BrowserStack session recordings providing timestamped video, logs, and exact failure steps, QA engineers could share a link directly with developers that contained all the context needed to understand and act on an issue. This eliminated the need to manually reproduce failures for developers, saved time on both sides, and reduced the back-and-forth that typically slows down bug resolution cycles.

7. QA engineers redirected toward exploratory and functional testing. With the manual, repetitive work of device-type testing eliminated, QA engineers were freed to focus on exploratory testing and improving functional coverage. This shift represents a meaningful change in how quality engineering capacity is used across the organisation.

8. Geographically accurate testing through device and region coverage. Elsevier was able to test its applications with the right device profiles for each target geography, ensuring that features worked correctly for Android-majority markets as well as Apple-heavy ones, and that regional redirections and localised content behaved as expected without requiring physical hardware in every location.