3 out of 10 apps get uninstalled after 30 days of deployment, according to Statista, the global business data platform. Most of the time, the main culprit of this is related to technical issues.
Therefore, what happens with an app that has constant glitches, crashes all the time, or takes too much of your device’s memory? It gets uninstalled. To prevent such things from happening, app developers need to make sure they repeatedly test it on multiple devices and versions of the same operating system.
Our colleagues at HPM, Eduard Rus and Mirel Lăpușan, recently worked on elaborating a CI/CD testing procedure within the company. The purpose behind their initiative was to avoid a bad onboarding experience for their application’s users and focused their efforts on testing as much as possible.
Continuous Integration (CI) represents a software development practice, the act of bringing together smaller components into a single system that functions as one. In other words, it means automating the process of combining multiple parts of the project into a single continuous working cycle.
From manual to automated testing
Mobile app testing represents an imperative part of any development project, but when time is limited, it becomes difficult for a developer to do consistent manual testing for an app. This happens particularly when it comes to regression testing, that implies checking all the app functionalities for every new version to make sure that the app still functions within the normal parameters, and that the new functionalities haven’t created any functional issues to it.
Regression testing represents an already performed test cases which are re-executed to ensure existent functionalities are still working properly.
Bug-free and time-saving are the basis of our colleagues’ development philosophy, even though automated testing does not necessarily represent a new concept in web or API testing. However, in their case, the story changes and it gets a bit more complicated as mobile testing needs an emulator on which to run the tests.
First steps towards mobile automation
During the first phase of the mobile automation process, Eduard and Mirel started writing the automated tests for the user interface of an app named CiteaGo. It is a parking application developed for Hectronic, that allows users to pay for their parking spot in a certain selected area.
The tests were written using Java with the cross-platform mobile framework Appium. Because the app they worked on comes as a white label, it is divided into a series of different applications. This means that each of them can have a different design and separate functionalities while sharing similar coding parts. Hence, it was necessary to separate the tests made for every iteration of the product and of course to run different tests for each release in part.
Automation, from A to Z
Time was still an inconvenience as the processes described took a lot of time. In consequence, their next move was to automatize the entire process from development to release. In order to create an automatization pipeline, that was integrated with Gitlab, they used the Jenkins tool following the flow explained below:
- The developer pushes a commit with certain changes or functionalities on a certain branch mentioning in the comment section of the commit the name of the application he wants to run the tests on.
- Jenkins creates a local copy of the project on the machine it runs on. his copy is taken of the mentioned branch (in this case, the development branch).
- After that, Jenkins has a job that builds the app automatically without the need for the developer to build it manually and then runs the automated tests on the new variant.
- During the last stages, if the tests were successfully run, the final version of the app that was automatically created is sent at the first step (using firebase).
- The testing results are sent on email to the assigned people.
Jenkins is an open-source CI server able to deal with a chain of actions that helps to obtain the CI process in an automated fashion.
The main purpose of this automation process was to simplify the work done by a mobile developer as much as possible. During the procedure, their automation tests covered the following:
- Functional Testing
- Usability Testing
- UI Testing
- Performance Testing (Stability)
- Change Related Testing.
