Customer storyHow InMobi connected mobile and backend validation in CI
A shared release workflow for app, API, beacon and downstream checks — replacing distributed desktop tools with a CI-triggered runbook that cut full regression from 2 days to 3 hours.
Full regression cycle
2 days → 3 hours
Automated runs in first 3 months
738
Runbooks triggered through CI
4
Reusable stable scripts
~100
QA capacity freed per week
~50 hours
Regressions caught before release
12
Backend / beacon failures invisible in UI
5
InMobi builds mobile advertising infrastructure for app publishers and advertisers. Its platform includes publisher SDKs for Android and iOS, an ad exchange, a demand-side platform, and backend services that support ad delivery, bidding, measurement and reporting across a global network. That architecture makes release validation broader than checking whether a screen renders correctly — a mobile journey may complete as expected while the related beacon, API payload, database state or downstream service is wrong. InMobi's QA team therefore had to verify both the user-facing flow and the systems that processed the event behind it.
Why the existing workflow did not scale
Before the new setup, checks were spread across separate tools and manual steps. Mobile execution was tied to individual workstations, while backend and beacon validation had to be performed separately. This made full regression slower to coordinate and difficult to run consistently through CI.
What the team needed was a shared release environment, CI-triggered sequencing, reusable stable flows, and evidence that connected each mobile step to the API, beacon, database or service outcome behind it.
UI checks did not confirm backend outcomes — completing a user journey in the app was only one part of release validation. The team also needed to confirm beacon events, API payloads, database state and downstream service updates. A mobile flow could appear correct while one of those checks failed.
Release execution was distributed across individual machines — desktop tools on individual workstations made it difficult to use one release process across the team. Test cases, device access, execution history and reports needed to live in a shared environment callable from CI on a release cut, on a nightly schedule or on demand.
Stable and changing flows required different execution methods — AI-based execution helped when screens or navigation changed, but repeating the same reasoning for a stable flow added unnecessary time and usage. Fixed scripts were faster and deterministic, but required maintenance when the interface moved. InMobi needed a way to use each method where it was most appropriate.
The implementation principle
The team kept changed surfaces flexible and stable paths repeatable. Backend checks were treated as first-class release conditions rather than separate manual verification after the mobile run.
Four decisions that shaped the setup
Each principle addressed a specific gap in the existing workflow — together they formed the foundation for the release programme:
Centralize execution
One dedicated Quash instance held test cases, connected devices, reports and run history for the QA team — replacing individual workstation dependencies with a single shared environment.
Trigger through CI
Runbooks could start on a release cut, nightly or on demand without depending on a tester's workstation. The same release sequence was callable from CI at any point.
Reuse stable flows
Validated mobile paths were saved as scripts and replayed deterministically in later runs, without re-running AI-based reasoning on flows that had not changed.
Check the state behind the screen
API, database, beacon and downstream service validations ran at defined checkpoints — as first-class release conditions, not a separate step after the mobile run.
One release sequence, with separate evidence at every layer
InMobi runs the workflow on a dedicated Quash Enterprise instance. A runbook controls the sequence, combining saved scripts, AI-based mobile execution and backend validation. Each layer remains a separate check — the report shows whether a failure came from the UI step, an API contract, a beacon event or a downstream service.
CI starts the runbook
The same release sequence can be triggered on a release cut, on a nightly schedule or on demand — without depending on a tester's machine.
Stable paths replay as scripts
Completed AI executions can be saved as scripts. InMobi built approximately 100 reusable scripts during the first three months, making routine checks deterministic and fast.
Changed areas use AI-based execution
Flows affected by product changes continue to use adaptive execution instead of relying on fixed steps, so the suite stays current without manual script updates.
Backend checkpoints validate outcomes
The sandbox checks APIs, database schemas and values, beacon events and internal services in an isolated environment using encrypted tokens — as part of the same run.
A custom MCP server gives the orchestration layer access to InMobi-specific domain actions and data while a test is running. This allows the release workflow to use the company's own business logic alongside mobile and backend checks, rather than treating every execution as a generic screen sequence. The final report keeps steps, outcomes and failure evidence together — a reviewer can see which layer failed without reconstructing the run across separate tools.
Before Quash
After Quash
What changed in the first three months
The pilot started with four runbooks covering the highest-value release paths. After six weeks, the team had confirmed that an AI-executed flow could be saved and replayed as a deterministic script. During the following six weeks, the library grew to approximately 100 scripts and the programme reached 738 total runs.
Across the first three months, the suite caught 12 regressions before release. Five were backend or beacon failures that were not visible through the mobile interface — the class of issue the previous workflow would have missed entirely.
The full regression cycle moved from two days to three hours, while roughly 50 hours of weekly QA capacity shifted from repeated backend and contract checks to exploratory work. The programme increased repeatability without making every run dependent on AI-based execution. Figures were supplied by InMobi and Quash and reflect the first three months of the CI-integrated deployment.
