# How We Cut WMG's Release Cycle to Five Days

[Michal Stanek](https://www.strv.com/blog/authors/michal-stanek)  
Director of Engineering

[Gabriel Pavlik](https://www.strv.com/blog/authors/gabriel-pavlik)  
Test Automation Engineer

---

**TL;DR:** Warner Music Group's Ada Hub platform relied on seven testers and a two-week manual QA cycle for every release. STRV replaced it with an automated Playwright test suite wired into the CI/CD pipeline. Release cycles dropped from two weeks to five days, the full regression run went from three-plus days to 20 minutes, more than 90% of critical user journeys are now automated and the team catches roughly 50% more bugs before production.

When I joined the Warner Music Group project, I was working on Ada Hub, the platform WMG built to help independent artists and labels distribute their music. It was already live, growing and supporting a fast-moving indie business. Their web platform handled more than 10,000 active users a month, so quality mattered. They were protecting it the way a lot of teams do: by testing everything by hand. Seven testers, full coverage, every release.

The effort was never the problem. All of that careful work had simply become the bottleneck.

### Why Does Manual Testing Slow Down Release Cycles?

Every release took two weeks. And most of that time was seven people re-running the same regression checks by hand. With multiple squads shipping in parallel across interconnected systems, the work was thorough and the catches were real, but the cycle was so long that fixes piled up behind it. Bugs that did slip past stayed live longer than anyone was comfortable with, because the next chance to ship a fix was always a week or two out.

I've seen this pattern on enough projects to recognize it fast. The trouble starts when manual testing is the only gate, so the release cadence can never move faster than people can click through test cases. That's a structural limit. Adding more testers scales the cost; the gate itself has to change.

### How We Approached The Automation Build

We started by mapping the existing workflows before writing a single test. I wanted to know where coverage was actually thin, where the same checks were being repeated and which journeys would break the product if they failed. That map is what kept the suite from becoming a pile of brittle tests nobody trusts.

One finding stood out: the release pipeline itself. A music release moves through a series of processing stages on its way to distribution, and backend engineers, not QA, were confirming each stage manually: trigger it, wait, check that it completed, move on. Around 30 scenarios, every release, in every environment. The product's most critical flow sat outside the formal QA process entirely, so we brought it into the automated suite, where those checks now run on their own.

From there, the build came together in connected pieces:
- A UI test automation suite covering the journeys real users hit most
- End-to-end and integration suites, built on Playwright, so problems surface where systems connect and not just inside isolated components
- A scalable framework built to grow with the product instead of cracking as it changes
- CI/CD integration through GitHub pipelines, so tests fire automatically on every build
- A regression suite that runs every day and returns answers in minutes

### What Actually Made This Project Succeed

The single biggest factor in making this work was getting the flaky tests under control. Flaky tests are where most automation efforts quietly die. [Martin Fowler wrote about this years ago](https://martinfowler.com/articles/nonDeterminism.html): a suite that fails at random trains everyone to ignore red builds, and once people stop trusting the results, you've spent months building something nobody looks at.

We put real time into stabilizing the runs and migrating hundreds of existing end-to-end flows onto reliable automation, all without halting delivery while nearly 30 engineers across WMG and STRV kept shipping. That unglamorous work is what turned the suite from a demo into infrastructure the WMG team relies on every day.

### The Results, By The Numbers

Here's where the project landed. The release cycle dropped from two weeks to five days under a single sprint. Critical user journeys went from manual-only to more than 90% automated across browsers and devices. The full regression suite, which used to take three or more days manually, now finishes in 20 minutes. And as the team shifted from manual testing to automation engineering, defect detection climbed roughly 50%, with far more bugs caught before they ever reached production.

The defect numbers matter as much as the release speed. Because the regression suite runs every day, issues that used to surface weeks after a change now show up within hours, while the change is still fresh and cheaper to fix.

With automation handling the repetitive regression passes, the two automation engineers who now maintain the suite moved into exploratory testing and deeper analysis, the work that genuinely needs a human looking at it.

### What I'd Tell Another Team Facing A Slow Release Cycle

If your releases have quietly stretched to two weeks or three, the instinct is to add more checks and more people. From what I saw on Ada Hub, that's usually backwards. The teams that ship the fastest are the ones that automated the repetitive parts of quality so well that a fast release is also a safe one.

Getting there takes discipline more than it takes any specific tool.

- Know which journeys are critical.
- Build a framework that won't rot as the product moves.
- Do the boring work of stabilizing flaky tests, because trust in the suite is the whole game.

Once that foundation is in place, every release after the first one runs on it.

In 18 months, Ada Hub expanded into physical distribution for the first time, cut release cycles by more than half and reduced submission errors to the world's biggest streaming platforms. Reliable automation is a big part of why that pace held.

---

Don't miss anything