How not to test a mobile app


Influence of microservices on mobile testing

Let’s imagine your company has started the transition from monolithic to microservice architecture, and now every back-end service can have a feature on the front-end, and specifically in our case in the mobile appl.

The standard test approach no longer works. Why? Let me tell you of a story that happened to my colleague from “PickPuk” (pseudonym).

My friend joined a new company right at the moment when they started cutting a monolith into microservices. After some time, he had to test a new feature, and as a professional engineer, he did two things:

  • Conducted a survey of the service developers who were responsible for the functionality of the feature, and received a response that the service was already covered by auto-tests and determined by the exact values of the input and output through the API.
  • Analyzed the new functional and UX features in the mobile app.

He came to the conclusion that it is mandatory to focus on the tests of a mobile device: matrix of devices, OS, functional testing, UI/UX, etc.

After finishing the sprint and releasing a new feature, what do you think happened? A bunch of bugs started to appear, which surprised my colleague because the client part had been very well covered. What had happened?

After the initial analysis, it became clear that all the bugs on the client-side were due to errors occurring on the back-end side, or rather in the new service.

Decision time

First step: Awareness

The first thing my colleague did was to once again look at the architecture of the entire system. And, he immediately realized that:

  • The mobile app was acting as a presenter and a solution transmitter from the client-side to the back-end service;
  • All the logic of decision making and other critical functions had almost completely moved to the back-end;
  • It was necessary to use multi-tier architecture.


Second step: Full Stack approach

Our hero decided that any feature that represents a particular service should be cross-systematically analyzed, planned and tested.

And thus, the following problems were solved:

  • Problems of “dark zones” – black boxes
    The team responsible for the service had to fully describe its operation and the relationship with the other services
  • Problems with integration
    It became clear where the internal and external features and services started and ended, both in the mobile application and on the back-end
  • Problems with the coverage
    The emphasis of testing had shifted to the back-end, which made it possible to optimize test coverage

Let’s look deeper into the question of coverage.
The mobile application was covered by GUI, functional and integration testing, while the back-end service with automatic unit, component and integration tests. All this was planned as a single test solution that complemented each other.

But, even with this decision, there was still one problem.
The system consisted of a huge number of microservices that constantly changed, increasing the probability of errors. Therefore, it was necessary to introduce risk management processes.


Third step: Risk Management processes

First, it was decided to use the tools for collecting statistics and analysis on which devices and OS are most used by clients. Then they introduced tools that allowed them to receive a report about the client’s failures and bugs in real time.

The next step was the development of the process of rolling out a new client version in production, to minimize the risk and regression in case of new bugs. It consisted of the following:

  • Testing in post-production. The moment the new version of the back-end system was rolled out and passed stabilization, it was necessary to check the candidate’s client release for correct work in the real system. If everything was fine, they moved on.
  • A new client version was introduced to a small group of randomly selected users, and then they waited for some time to get the first results of monitoring problems. If everything was fine, the process was repeated until all clients were fully updated. In case of a bug, it was analyzed and prioritized. If the bug was critical – it was removed, and the process repeated from the beginning. It was at this point that there may have been new bugs and weak points in the productivity of the entire system. But, they had solutions for it…
  • …”Chopper for a feature” – a lifebuoy in such a situation. This is basically the ability to disable a feature that jeopardizes the performance of the entire system as a whole.

By using this solution in full and on a permanent basis, my friend and his team reduced the possibility of critical bugs in production in cross-platform features to a minimum.

So do not forget that mobile features today are already part of the microservice systems, and they require a new test approach.

Wish you more features and fewer bugs!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.