Skip to content
, Home

ResultsCase study 01

Sustaining quality across two mobile apps and their content delivery platform.

The Economist app, the Espresso app and the platform behind them: regression for the flagship app went from 4–5 days to 1–2 hours of automated test execution, while collaboration, layered automation, platform integration testing and physical-device coverage helped sustain ratings of 4.9 on the App Store and 4.8 on Google Play.

Organisation
The Economist · News and media
Period
2021–2025
Role
Senior QA/QE Manager, mobile and content delivery
Capabilities
  • Quality & scale
  • Quality engineering
  • Test automation
  • Integration testing
  • Device testing

Challenge

Maintaining ratings of 4.9 on the App Store and 4.8 on Google Play required consistent attention to the experience behind every release. At The Economist, my work covered two mobile products (the flagship The Economist app and the lighter Espresso app) alongside the wider content delivery platform that supported them.

The challenge was to keep both apps reliable, responsive and consistent across devices while supporting new features and changes to the underlying platform.

Baseline

The starting point was a regression cycle of 4–5 days before a release of The Economist app, the flagship of the two.

My role

As Senior QA/QE Manager, I worked closely with product and engineering to embed quality into feature development. My remit also included managing quality across the wider content delivery platform, with my team testing the platform and its integration with the mobile apps. That meant considering the complete journey from content delivery through to the reader’s experience, including how platform changes could affect either app.

Intervention

Making quality a shared responsibility

With product and engineering, we established expected behaviour, identified risks and agreed testing approaches early, giving teams a shared understanding of what was needed for a confident release.

Building confidence through layered automation

A high level of automation across testing layers supported this approach. Focused checks at lower levels, integration tests and end-to-end coverage worked together to validate individual components, interactions between systems and key user journeys.

Testing the apps alongside the content delivery platform was essential. Components could work correctly in isolation while problems emerged at their boundaries. Integration coverage helped us assess whether changes across the platform and mobile products worked together as intended.

Testing on physical devices at scale

Device-farm integration enabled automated testing across a broad range of physical devices, extending coverage beyond the hardware available locally.

Alongside functional testing, we measured performance and stability across different devices and operating-system configurations. This gave the team evidence about how the apps behaved under real device conditions and helped identify issues that narrower coverage could miss.

Evidence

Regression before a release of The Economist app went from 4–5 days to 1–2 hours of automated test execution, while ratings of 4.9 on the App Store and 4.8 on Google Play were sustained.

Starting point
4–5 days per regression cycle
End point
1–2 hours of automated test execution
Unit
Time taken by regression before a release: days at the start, hours of automated test execution at the end
Scope
The Economist app, the flagship of the two apps
My contribution
I connected quality across the mobile apps and the platform behind them: making testing repeatable, performance and stability measurable, and release decisions grounded in evidence.
Other factors
The ratings reflect the work of the wider product and engineering teams, not of testing alone. The shorter regression has not been isolated from other changes in the same period.

Caveat. The end point is the time the automated tests took to run, not the length of a whole regression cycle. Both figures are approximate ranges; the period and method of measurement are not published, and no percentage improvement is claimed. Store ratings are public averages that move over time.

Limitations

A shorter regression run is not, on its own, evidence of fewer defects or of better releases. A store rating says how readers rated an app, not how many defects reached them.

Want to improve release confidence and delivery flow?

Describe the team, the pipeline and what is getting in the way.