In Part 1 of this blog series, we talked about the history of mobile development. What’s next? Let’s dig into what happens when you automate mobile testing.
Today, people understand that automated tests are the key to shipping your product with confidence. Think about how a bug could impact your business: When a bug is found in production you need to stop the work, assess the bug’s severity, identify the bug’s origin, fix it, review code, test the fix, and deploy. This is just the “dry” tax. What about UX and your business’s reputation? Automating your mobile testing can help you uncover problems well before production, when it’s much cheaper and easier to rectify them.
So what are the limitations of automated mobile testing?
In web automation, besides the vast range of tools like Tricentis Testim, Selenium, Puppeteer, or Playwright, E2E tests are executed on a browser. Working with grid providers like BrowserStack or Sauce Labs makes it easy to get as many browsers as we need. But in mobile automation, our apps will run on a physical device — so we need to test on a physical device.
First, a developer will need an OSX-based computer, because iOS development can only be conducted on OSX. We also need an iPhone and an Android device. Yes, development can be done on a virtual device that Xcode or Android Studio can supply, but that is not the same as a physical device. If we need to check the app with a camera or GPS, the emulators may not be a good choice or may give false-positive results when compared to real devices.
Second, you must choose a tool. The most common tool for setting up automation is Appium, and a lot of the grid providers like Headspin, BrowserStack, or Sauce Lab support it well. Appium helps us to orchestrate everything that relates to the automation of the test: working with a device, installing the app, initiating a session, and performing actions like tapping, swiping, or closing the app. Be aware that iOS devices may have restrictions and you will need to find your way around them.
Third, after you’ve authored the first automated test (a login flow, right? That is the best flow for a first test), you need to set up a CI/CD pipeline that will run the tests with the current change in any branch (or execute them before deploying the app). In my opinion, if you are not an iOS/Android development wizard that can be a headache, because you need to compile the iOS app on an OSX machine and they are not as cheap and accessible as Linux machines. If you look at the GitHub actions pricing page you can see that the usage for a Mac machine is not cheap either; my suggestion here is to use Fastlane or a third-party provider like Bitrise.
Introducing Testim Mobile
Fortunately, Testim Mobile solves a lot of the problems we had in web automation but for mobile.
The first is device orchestration. Managing devices and understanding which physical or virtual devices are available for testing requires xCode or ADB command knowledge. We also need to be able to install the application on the device. For an Android device that’s easy, but for an iOS device it’s a bit tedious because you need to provision the app to the current development organization that the iOS device is assigned to. For an organic team that’s not a problem – they are registered to the same Apple developer team. But if we consider a consulting company, they’ll need to provision any app a customer will provide for writing the automation tests. That’s a doozy.
Before starting to author Testim Mobile tests, download TMA (Tricentis Mobile Agent). After setting up TMA on your local machine you are ready to start authoring tests on any device you own. With TMA you have visibility into which devices are available for authoring tests. What’s more, Appium comes pre-installed so the development team will be aligned with the Appium version and strange bugs related to mismatching Appium versions won’t pop up.
The second pain point that Testim Mobile solves is the management of mobile application files. There’s no need to pass around the ipa/apk files. When the developer or QA engineer uploads the app to Testim, it’s visible to all the team members on the project along with information like the app’s identifier, name, version, and whether it’s a build for virtual or physical iOS device.
The third problem — and potentially the most important one — is the authoring of the test. When you author the test the AUT shows you in real time what’s going on in the device. You can interact with any element, just as you do in a web-based application. Smart locators powered by our AI model will help you get more stable tests. If a test failed because of a change that a developer made, or if you need to update a test due to a change in the STP, you can play a test or record it from an app existing on the device – virtual or physical. Thus, you’ve eliminated the need to compile the app after each change to ensure the test will work with the new version.
Once your tests are ready, you can manage them with labels, test plans, schedulers, or suites and play them on grids like Tricentis Device Cloud. If you have BrowserStack or SauceLabs grids for your web projects, you can use them with the same credentials.
Conclusion
In summary, mobile automation presents unique challenges, especially regarding device management and test authoring. However, solutions like Testim Mobile streamline these processes, offering real-time interaction and AI-powered locators. By simplifying device provisioning and test execution across grids, Testim Mobile enhances efficiency and quality assurance in mobile development workflows.
