At the end of 2023, we ran our first Autifyathon within Autify. Autifyathon is a hackathon by engineers, for engineers (and customers, of course), where Autify engineers can work on projects of their choice at their discretion. The purpose was to:
The structure was as follows:
This was an ambitious endeavor where members could work on whatever they wanted for almost a week. A total of 13 projects (teams) were formed, and each team presented their efforts on the final day.
All teams produced some kind of result they could present as a PoC within the given timeframe. Most were improvements we wanted to make in our daily work or product-related ideas we wanted to try. After the award ceremony, we had a party at the office to celebrate our achievements, and the event came to a close.
Here are two projects that teams worked on at Autifyathon. Both are related to Autify for Mobile because I (the author of the original Japanese article) work on Autify for Mobile (I can explain the technical details accurately).
Autify for Mobile has had a fundamental problem for many years: iOS test scenarios have to be run on a VM, and it takes a long time to launch the test scenario creation environment. Every time you run an iOS test scenario on Autify for Mobile, a new simulator has to be prepared on macOS in the cloud – this takes a significant amount of time. This is partly due to the fact that, due to security concerns, a clean environment is prepared each time.
In this project, the team aimed to speed up test scenario creation by building a desktop application with Electron and launching the simulator in the end user’s environment rather than in the cloud. If successful, this could also reduce the cost of maintaining the VM environment.
In the existing environment, as you can see in the figure below, the user interacts with the mobile application in the iOS simulator, running in the cloud, via a web application.
With the desktop method shown below, the simulator is launched directly in the user environment, allowing the simulator process to be reused without security concerns. This makes launching the scenario creation environment extremely fast from the second time onwards.
The team implemented some features as a PoC, demonstrating that this method can improve the product.
Autify for Mobile uses a third-party tool called Appium to run tests on native iOS mobile applications. To identify test elements (such as buttons and forms), Autify for Mobile retrieves an XML file from Appium that describes the UI structure – this is called the page source. However, retrieving the XML file can take a long time if the mobile app is complex. This results in a poor user experience when creating test scenarios in Autify for Mobile.
To retrieve the page source, Autify for Mobile employs a software called Appium WebDriverAgent, which is used within Appium (it’s actually an XCTest process that can be controlled remotely). In this project, the team thought that developing a test driver to replace WebDriverAgent could improve the page source issue. First, they decided to investigate what part of WebDriverAgent was taking time. The team worked on the project in the following steps:
In the end, the team found that most of the time was spent on retrieving attribute values, which are essential for identifying elements. In other words, time was not being wasted on useless processes, and speeding things up would be difficult (they found that while some performance improvements could be achieved by retrieving the minimum number of attributes, the effect is unlikely to be significant).
On the other hand, the team also made an unexpected discovery through this project that could lead to product improvements. When Autify for Mobile launches the simulator environment, it would be ideal if we could have multiple simulator processes on standby at the same time so that the scenario creation environment could be ready quickly. However, launching simulators at the same time was challenging due to Appium’s limitations (it was impractical because the simulators would be launched sequentially).
However, while building the WebDriverAgent development environment at the beginning of the project, the team found a workaround to the limitations. This will help solve the startup time issue, which has been a serious problem in supporting multiple operating systems. Recognizing that this discovery could have a significant benefit to the product, the team revised the scope and goal of the project and presented the reduction in startup time as their primary achievement.
Autify held an internal engineer-led hackathon called Autifyathon, where 13 teams worked collaboratively over four days on projects such as PoC implementation and bug bashing. Many of the achievements have been turned into product backlogs and the development team is working on reflecting them in the actual product.
At Autify, we are looking for people to help us improve our product. If you are interested in working at Autify, please visit our careers page.