Mobile UI Test Roadmap — Part I
This is the first blog post of our UI Roadmap that we use on our mobile application. Please feel free to share your comments. Have a nice reading!
With the rapid development of technology, mobile applications have begun to enter our lives more and more every day. As in every software project, it is to offer error-free products at the maximum level so the target users can use without encountering problems in mobile software. In order to control the quality part, there are individuals who have the role of test engineer or QA engineer, responsible for quality and testing within the software teams. Individuals in these roles take an active role in the analysis phase of the projects, during the development phase, after development, before and after releasing product. In short, test engineers are involved in all processes. As software projects grow, testing becomes more difficult, and as the effort of the tests increases, the time spent on testing increases. When generalizing here, two main topics can be mentioned, namely manual tests and automation tests. These two practices are parts of an inseparable whole. We can say that we prefer automation for repetitive tests. In this article, we will share with you the roadmap of the UI test section, which is the automation side of the mobile application that we have developed.
What is Mobile UI Test ?
The main purpose of software testing is to verify that an application meets the requirements and to catch errors that may occur during the application development process. Also prevent possible errors that may occur when the product is presented to the user in the future, by ensuring that errors are noticed before app is presented to the user. After the improvements made on the existing application or new features added, it may be necessary to test the entire application. Often, when there is a need for regression at this stage, test engineers may encounter some issue what we call tester blindness. At this stage, when we use automation for cases that are repetitive and frequently run in mobile projects, we come across UI tests. UI test stands for user interface test. We can write UI tests in two operating systems, Android and iOS. We are using Kaspresso framework for Android and XCUI for IOS. We can also include navigation and unit tests when writing UI tests.
Why Did We Need UI Testing in Our Project ?
So why did we need UI testing in the our project? What are the pros and cons of starting automation in a project that has just started and has not yet reached its final state? There were various opinions in the process of deciding whether to start UI testing in the early stages of the project. We were determined to use automation in our project. After researching various automation tools, we decided that the Kaspresso framework for Android was the most suitable for our project structure. Kaspresso has a simple syntax and it was more suitable for application to the project we developed.
The fact that we decided how to proceed in our automation process in the very early phases of our development process, leads us to create UI test infrastructure also early. In addition, when compared to creating an automation structure with an old project that has become large and complex according to our past experience, we concluded that it is more feasible to set up the test automation structure for a new application with simpler flows. Thus, we write UI tests for screens that have been developed and finalized. We also update the UI tests we have written in case of new screen implementations or additional requests added for old screens and changes performed in visual design and flow. Thanks to the fact that our scenarios are up-to-date, we use our automation structure when regression is required. We also support the parts that cannot be automated with manual tests. We use UI tests because we can minimize the test run cost on test engineers by using UI tests and because it is applicable to our project. In summary, our purpose for using UI tests is:
- Ability to control the same screens frequently and quickly
- Minimizing tester blindness
- Providing a continuous test run
- Reduce the pressure on test engineers
- Revealing bug-free software
What are the Challenges of Using Mobile UI Testing ?
As we mentioned at the beginning of our article, manual testing and automation testing are not separate things. When both are applied correctly in an application in a coordinated manner, it will most effectively assist the test engineer in finding bugs in the software. So what are the challenges of developing an automation?
Many cases can be found for functionality during tests. So there will be a lot of cases that need to be tested. However, it is not always possible to automate everything. Even if possible, it would be very costly to write all the cases. Here, cases consisting mostly of happy paths will be automated in the regression form within the scope of the tool’s competencies. The test engineer, on the other hand, can test different cases according to his/her knowledge and catch possible errors during manual tests. Another problem is that while an application works correctly for a device or operating system version, it may receive an error, specific to another device. UI test scenarios should be written with this scope. This situation can cause contractions in the scope of UI test scenarios.
Another challenge of UI testing is when introducing different screen elements to automation. For example, it takes a lot of effort to include screen elements such as date picker, picker view or custom diaglogue in scenarios. This situation varies according to the strength of the framework used.
Write UI Test Automation with Kaspresso
Under this title, we will try to explain the implementation of a simple test flow with the Kaspresso framework.
- Importing Kaspresso to Project with build src
- Create ActivityBaseTest Class
With ActivityBaseTest, purpose is building a base structure for testing Activities that showing UI directly or Activity(Single Activity Pattern) that showing UI through Fragments. Constructor accepts Activity Class which will be running with ActivityScenario, and the intent is for testing different situations for Activities.
Writing Before and After functions in ActivityBaseTest, allows every test classes to override the startup and end process. And onStart and onFinish, for example if project is using dependency injection, test class can inject it’s dependencies with implementing onStart and unload dependencies with implementing onFinish(). Of course, it can be usable for initializations too.
Android UI and Navigation Tests Structure Pattern
We are using two components for each screen test. One is UI Test which running tests for all cases with combinable functions. The other one is Screen which contains UI components and related functions that every function has one test case.
As seen in the example, there are two UI components and for each UI component, there is a case. The cases includes whether the component is visible or displayed and whether the component has text content equals to “example”.
In this example, ExampleActivity creates the screen to be tested. ExampleActivity class object passes through ActivityBaseTest as parameter. As ActivityBaseTest is the parent class, we need to implement onStart and onFinish functions. If you want to inject the dependencies for this activity or initialize other classes, it should be written at onStart function. If you want to destroy or change value after test, it should be written inside the onFinish function. Also, Screen component(ExampleScreen) should be field in UI Test component so we can run through screens cases. So the remaining part of UI Test component are tests that created to run. You can run multiple cases through a single function. This part can be changeable depends on how you want to write test functions.
Every project has its own dynamics. In this article we tried to explain the UI Test infrastructure that we used in our project. In our upcoming articles, we will share posts in which we will explain the solutions we have made in this context and the practices we have found.
Thank you for your contributions Tuğba Top, Berkay Turancı, Nilay Dagdemir, Göksun ÖNAL.
