From Zero to QA Hero: How spriteCloud Built a World-Class Quality Engineering Function at citizenM

A hotel chain built on technology

citizenM runs affordable-luxury hotels across Europe, North America, and Asia. Self-service technology carries the guest experience: guests book, check in, and control their room through a mobile app, iPad units handle in-room lighting and media, and a Property Management System ties it together behind the scenes.

None of that technology was tested as one system. Guest apps, iPad controllers, booking platforms, and the PMS had been built by different suppliers, on different timelines, with no shared quality process.

Zero QA, five suppliers, one guest exploit

When spriteCloud started, citizenM had no QA process, no test documentation, and no function that owned quality across the estate. Development ran as a mix of Kanban and Waterfall, split across external suppliers who each worked to their own standard. Some had mature engineering practices. Others had no version control.

Quality sat entirely inside supplier teams, so citizenM had no visibility into whether a release was actually ready and no way to enforce a shared bar. Test environments were just as inconsistent: some systems integrated straight into the PMS, others through middleware, which meant duplicated logic and hidden architectural risk.

Years without QA oversight had also built resistance. Introducing testing as a required step in the workflow read as an accusation to teams that had shipped without it for years.

The clearest sign of the gap: a guest-app exploit that let people check in for free had gone undetected for years. It surfaced only once integration testing started.

The instinct was to fix this with test automation. spriteCloud's assessment found the opposite: automation would fail without an SDLC to sit on top of. That call shaped everything that followed.

Start by finding the real problem

spriteCloud ran a structured quality maturity assessment across every supplier and development stream: interviews with product owners and developers, a review of SDLC practices, an audit of integration models, and a map of testing scope and risk.

The finding: engineering maturity varied wildly, and test automation, the thing citizenM assumed it needed, was premature. The organisation needed defined processes, clear roles, and quality gates before a single automated test would hold up.

One engineer, two products, and a lot of trust-building

Maryna Volovenko joined as citizenM's first embedded QA engineer, splitting her time across Membership, a new product for loyal guests, and the public website, built by a mature external team in Germany that did not want outside QA involved.

She started small: lightweight test cases and early feature reviews folded into the existing workflow, not a rebuild. Every bug caught before production got framed in terms of business impact, not blame. QA was positioned as part of the team, not a policing function.

It worked. citizenM saw the value and approved expanding the engagement.

An SDLC first, then automation on top of it

With buy-in secured, Test Architect Umut Ay Bora joined to design a company-wide SDLC: a Development environment for active feature work, a Test environment for integration testing, and an Acceptance environment for regression and release sign-off, customised per stream but governed centrally. Definitions of Ready and Done, structured test case management, and formal regression cycles followed. Executive approval and stream-level buy-in landed within about six months.

Only then did automation get built: UI automation for web and mobile, API testing across backend services, mobile automation for the guest app, and end-to-end regression covering login, signup, booking, and check-in. Automated suites replaced manual regression testing, which freed QA engineers for exploratory and integration work. As the team grew past 13 engineers, each new team got tailored SDLC onboarding.

The Sunrise migration: the highest-stakes moment of the engagement

citizenM decided to migrate its Property Management System from a legacy platform to a new cloud-based one, internally called the Sunrise migration. spriteCloud used the moment to fix the underlying architecture: middleware became the single integration layer for every front-end system, defined test environments per stream went in for the first time, and integration validation and cross-stream regression planning were formalised.

High-risk platforms like the iPad application got staged, phased rollouts instead of a single cutover, deploying updates across devices and locations incrementally to keep a bad build from taking down every room at once. The migration closed with zero critical production bugs in stabilised components, a result the preceding years of SDLC and automation work made possible.

The hard part was never the tests

The biggest obstacles in this engagement were organisational, not technical. spriteCloud ran change management in parallel with every technical workstream: aligning suppliers around collaborative quality practices instead of adversarial ones, moving QA spend out of siloed supplier budgets into centralised governance, and providing the assessment and rationale citizenM needed when a supplier had to be replaced.

As new QA engineers joined, spriteCloud built structured documentation and Confluence-based onboarding so institutional knowledge stayed in the organisation instead of leaving with any one person.

From no QA to a function that survived an acquisition

• 1 → 13+ QA engineers built over the 3.5-year engagement.
• 0 critical production bugs after the PMS migration.
• 3,000+ test cases migrated into Xray/Jira.
• 100% SDLC coverage across every product stream.

citizenM moved from ad-hoc, unplanned development to a company-wide SDLC with defined quality gates at every stage. Quality ownership came in-house, cutting dependency on suppliers for production-readiness calls. UI, API, and mobile automation gave repeatable regression coverage without growing manual effort in step with it. Structured documentation and Xray integration meant new QA hires could contribute fast.

The clearest sign of culture change: teams started asking for QA involvement instead of resisting it. Product owners got a reliable QA readiness read for the first time, and the quality function started shaping product direction, not just running tests.

The QA framework spriteCloud built stayed operational through a company acquisition. Processes, documentation, and culture held through a change in ownership.

From one embedded engineer to a team of 13, spanning 3.5 years: citizenM's quality function survived a company acquisition intact, because it was built into the organisation, not bolted on for the length of a contract.