Why mobile app bugs can cost more to fix than web bugs
Once a bug on the web is fixed, the change can be deployed centrally and the next visit already uses the new version. With a mobile application, a distribution channel and the device’s or person’s decision to update stand between the fix and the customer. A faulty release can therefore remain in operation even after the fix is ready.
Why a fix does not end with a new build
An update in Google Play may be subject to review and, once published, does not reach all users at once. Some have automatic updates enabled, while others update manually or only after some time. With a staged rollout, only a selected proportion of users receive the new release at first.
Multiple application versions therefore remain in operation simultaneously. Several of them may communicate with the same backend services, but may not support the same fields, rules or sign-in method. A fix for the new application consequently also needs to account for older clients.
If the team stops the rollout after discovering a bug, it limits the number of further installations. Users who already have the faulty version, however, need a corrective update or another way to mitigate the problem. This is another reason why prevention before release is more valuable than for a product that is updated on a single server.
How to reduce risk before release
We divide testing according to speed and environment:
- fast unit and integration tests verify the logic after every relevant change;
- a short smoke suite covers the most important journeys on an emulator;
- selected end-to-end scenarios verify physical devices and supported Android versions;
- before a larger release, installation, updates, sign-in, the main function and the payment flow in test mode are checked.
We choose devices according to product usage and the risk of a specific function. There is no need to run the entire suite on every model. It is more important to know which combinations we cover and why.
We incorporate tests into the process so that the result is available before the release decision. In the event of a failure, we save the diagnostic data permitted by the tool and internal rules: a log, screenshot, video or technical record of the steps. Their creation needs to be configured; it is not automatic with every solution.
Safeguards after deployment
Testing will not detect every possible bug. Risk is therefore also reduced by a staged rollout, monitoring crashes and key metrics, the ability to stop the rollout, and backwards-compatible APIs. For suitable functions, a configuration switch can help by temporarily disabling the problematic part without a new build.
Google Play also supports update prompts and in-app update mechanisms. Their use, however, needs to be designed according to the importance of the fix and the user experience, not as a substitute for prevention.
What you gain
In a controlled environment, automated tests can detect some faults in critical journeys before a public rollout. Such faults can be investigated and fixed without the pressure caused by a problem in production.
A staged rollout and monitoring can shorten the response to a problem that only appears in operation and, depending on the deployment method, limit the number of affected users. These measures do not eliminate every risk, but they give the team more information for its decision.
Next step
Review the last three production bugs and, for each one, determine which check or operational safeguard could have detected or mitigated it. Use the result to create a short smoke checklist and rollout rules for the next release. If the product also includes a web component, compare the process with automated testing of web applications.