Super App Test Challenges Part 1
“海千山千- Ocean thousand, mountain thousand” — Proverb by Yojijukugo
Before talking about the Super App Testing Challenges, I’d like to start with a few definitions. What is a single app, a super app, and a sub-app as we call in Trendyol ‘channel’ ?
Market, Meal, Dolaplite and International are our channels (sub-apps). We are planning to add new channels to our application.
Single app: An application with a single scope of business. For example, the calculator is a single app and functions only as a calculator.
Sub-app: Small apps combine to form the super app. For example, by using Trendyol application, you can also browse the market and meal application. Market is a sub-app.
Super app: It is an app concept where many needs can be met within a single app and more than one service can be accessed under one roof.
Nowadays, super app development is becoming quite trending. As Trendyol, we want to develop our mobile application as a super app, and want a user to perform any action that can be performed online through a single application, and we are trying to move forward with strong steps for this.
In this article, as Trendyol Mobile Team, I will share the information the challenges we encountered in testing processes while on the way to becoming a super app.
Let’s start with tackling below challenges.
Routing between channels
Dependency between channels
Common components used in channels
Memory management
Common data between channels
Routing between channels
Routing between sub apps should be as smooth as possible so that the user should not encounter a problem when switching from one channel to another. On Trendyol homepage, we have a banner that we direct to the channels. We have test scenarios where we control the routing to the channels thanks to the deep-links in each banner.
When the user turn to one channel and back, the opening speed of the other channel and the screen transition are very important for us. During the transition between channels bugs can be;
- Pages may not load,
- Load slowly or
- Crash.
In order to prevent this, we perform low-speed internet testing, low-battery testing, monkey testing and regression tests in test scenarios. We constantly test these controls and try to catch all bugs before the users.
At the same time, for example; If the user who switched to the market channel wants to switch back again our app loads the pages from the start. In this way, we also provide memory management. I will share the memory management challenge in the other topic.
Dependency between channels
We have some dependencies between our channels. To give an example, users can see all their orders on the trendyol My Orders page. Market, meal, dolap lite orders are linked to trendyol orders.
There may be bugs in the application due to dependencies between channels. For example; In order to switch to the International channel, we need to open My Account>My Account Information>Change Country>Country Selection Screen. Due to an error on My Account page, we cannot perform our tests on the international channel. We have deep-link redirects for pages due to dependencies.
- In order to be able to notice the problems that our users will encounter due to this dependency, we take technical tasks such as Modularization developments in our sprints and try to ensure that the interdependence runs smoothly.
- We use the New Relic tool to instantly intervene in the problems we encounter.
New Relic allows you to monitor your application and access error logs that users encounter.
Common components used in channels
Using common components can reduce development cost and app size. While planning our developments, some features are requested in all channels. For example: “Adding a user phone number to the delivery address field”. Or a UI component can be reused in other channels. Such as, the delivery address component on trendyol My Orders page is also used in other channels. These common components may also vary in all channels.
For example; we have My Orders page in market and meal channels. We use the delivery address field on this page as a common component. If we want to add the phone number of the user in the delivery address component on the market channel, this information should not come in the delivery address component on the meal channel.
One thing to pay close attention to on common components in different pages is that data that should be displayed in one channel should not be displayed in another channel (if not desired).
In order to avoid these problems, in case of changes in common components, we run our test scenarios specifically on the relevant pages in all channels.
Memory management
It is highly possible that there is going to be some memory management problems in applications that contains more than one app. For example, while the application is a single app, it occupies 200 MB of RAM on the device. The ram consumption of applications that contains more than one sub-app can easily be 500 MB. This causes the app to slow down. In order to prevent this situation, we are trying to run the following scenarios while testing all the features;
- When switching between channels,
- When trying to close and reopen a channel,
- While testing screens if include photos or videos.
Periodically, we include tasks to our sprints specific to keeping memory management problems under control. In order to minimize the dependencies between channels, technical story such as modularization and refactor are always present in our backlog.
We follow up on the errors while doing our Monkey tests. We are also trying to test the application in battery saving mode. If you want to look at more details on the subject, you can check the Memory Management title in my previous article below.
Common data between channels
In the app, we have more than one page where we store our users’ data. While making improvements, the changes we make in any channel should not affect another channel. While the user writes his/her address as A in one channel, she/he may want to write B in another channel. Right?
Considering all these scenarios, we proceed as follows; If the issue done in one channel affects or is likely to affect the other channel, developer add comments under issue in Jira. For example; “This development may also affect the international channel, it needs to be tested”. Through communication, tester working in the relevant domain run all their test scenarios, so that the changes we make do not disrupt other channels.
It is very exciting to be on the way to become a super app. We learn a lot as we cope with the challenges we face. We gain different perspectives, we think multi-dimensionally.
🏃♀️ I will share other challenges that we encounter in my next article.
Thank you for your time. I look forward to all your comments and suggestions about the article. Please do not hesitate about any questions or suggestions 🌟
