I think it is imperative to write an article on the problems we have experienced while developing mobile applications and the solutions we have found for these problems.
Process
Developing a mobile application is somewhat different from other software processes, giving you a product that can touch the end-user, can see errors very clearly; I say ‘can touch’ because when you swipe on a list, there is a glitch in the application of the slipper.
Services and applications, running in the background of the device and the working duration can make your application run poorly when it was working successfully in tests while you were developing the app.
The test processes of mobile applications and the time spent resolving these test outputs need not be underestimated at all, which is an inevitable consequence of a significant decline in motivation.
Because we are agile, we are pushing the test in parallel rather than leaving it at the end of the process, but by the diversity of mobile devices and cores in every version are broken the previous system? The question frightened us.
While applying agile, there is a team presence in the heart of the process and obviously, our team worked well and clean, but it can not guarantee that everything will be in order.
The situation should be marked as done after the test team has tested the modules written in the sprint according to the “definition of done” list and is sure that they work well on all devices.
Problem
Think of a team of 3 people working on a small project, one of them is a tester, checks the status of the application on all devices for two operating systems and does it over and over again.
This challenge led us to use test automation; first, we looked at the solutions on the market, and at the end of this review, Appium, an open-source solution, was more than we needed.
Appium was developed by Dan Cuellar as an open-source, who was Test Manager in a company, looking for the exact need and couldn’t find the one.
We found the solution we searched for, and we believed that this solution would solve all our problems.
Application
First of all, since a friend on the test team is familiar with the Java language, we decided to go through the Java client solution.
We were using Junit and Eclipse Ide, scripts that were triggered on Ide by working on the phone connected to that computer; Finding the UI element, clicking on it, writing, swiping fastened our work, ass this was a really impressive beginning for us.
In the following days, iOS testing requires Mac computers to test the team, and also hubs and cables to run multiple tests.
We switched these tests to NodeJ, which is said to work by spending little resources in every environment, to use a more flexible solution that we didn’t want to trigger the Ide.
Then we said we should work on all phones and shell scripts.
We wanted to schedule this work, to follow up on our reports, and we have completed the process by installing Jenkins.
Result
Now I look back and I do not understand how I thought that we completed the process :).
The setup was as following;
- 7 test phones in Device Farm
- Jenkins
- Test-Scripts
Day after day the devices became insufficient, they were constantly plugged into the hub, they started to break, we could not manage our test scripts, we were stuck with the challenges created by a parallel run over Jenkins, the applications were somewhere in the test-case documents and the automation codes were somewhere else. We learned how difficult it would be to facilitate our work with automation, instead of getting easier.
One of the problems here is that we have forgotten that we are only a small part of the regularly established test environment automation, and the other is when you combine a lot of the parts that does not mean you always create the Voltran.
Happy ending
We started from scratch, first of all, we made our test processes healthier with training, and made clear when we start the design tests, how we do the functional tests, where we activate the automation.
We wrote a panel that we could run on the Cloud and manage the whole process, we used Java Spring at the back, we preferred React.Js for the frontend.
We set up a special device farm for this solution, where we made the platform we selected ourselves finalized with a lot of trials and errors.
We read published articles to create a diner, joined online training, and even found out that this work alone required a lot of work.
In the end, we have built a healthy structure with its own rooms, camera systems, air conditioning, internet, lighting and UPS systems.
Thanks to this solution and the experience we have gained through this solution, the customers, our test team and also myself were happy.
Bonus
Then we realized, that we were not the only ones who live these and needs a solution. So we have produced a solution, we have talked in panels, in fairs, and today we have become a product preferred by the biggest organizations in Turkey.
We took the opportunity to participate in domestic/foreign events and talked about our solution, we got prizes.
This product now has its own support, sales, etc. teams.
I’ve done a lot of other similar products like you’ve read a short story about stages of product development created from an important requirement, and they all have their own stories and I will share them in time.
Finally, I would like to add that I met Dan Cuellar, who I mentioned at the beginning of the article, and that I had the opportunity to talk about the solution and that he was very impressed.
Thank you.
