This is Part 6 of our automation series. Read Part 1 to understand of how to get started with automation, part 2 for insight into reducing the flakiness of your automated tests, part 3 to learn about CI for automation testing and part 4 where we cover the API Testing.

When starting out with the automation of mobile testing, generally you will face multiple challenges related to accuracy, device-os combinations, test coverage, usability of the test itself. These challenges are very unique to mobile testing even though the scope of testing which remains similar to Web testing, the target of testing, which is mobile, is very fragmented.

According to a worldwide survey between mobile, tablet, and desktop usage conducted by statcounter.com, mobile usage crossed more than 50% in recent times and is still growing. The Android market is as fragmented as it could be, with iOS following in the footsteps and releasing multiple new devices, mobile testing is one of the toughest levels of testing at present due to the sheer number of devices to cover.

Now coming to the variety of actions and gestures that you can perform on mobile, which is increasing as well, presents a unique opportunity for developers to build new and radical solutions, making it painstakingly harder to automatically test.

With these challenges or opportunities, depending on how you perceive it, you would definitely want to run automated testing on a variety of devices however still would not want to maintain your code or scripts based on each device. This is where our patented single interface program and logic comes in!

Write once, run any-where, any-time, every-where, every-time

Using basic NLP, we try to make sure we write tests just for once on the basis of the target OS, say Android or iOS. With the help of our step functions and assistant functions we maintain a strict segregation of duty between different components making sure that writing tests is always a breeze and running those tests on a variety of devices is equally refreshing. That helps to focus on the actual application under test and you can write better tests without worrying about where and how it will run.

For example if you wanted to automate and just open the PayPay iOS App, you would just use the step of `Given I open “iOS” app` and it will run the same way and open the PayPay iOS App, be it on simulator, your device inhouse, or a device on cloud

Mobile automation testing helps PayPay catch over thousands of bugs in a year. We are always looking to work with people with ideas and experience, feel free to join us as a full-stack tester. If you are interested to know how we link the testing with dev workflow at PayPay stay tuned for the next post.