Automating the Testing of Mobile Application BITS ZG628T

Automating the Testing of Mobile Application
BITS ZG628T: Dissertation
ID No. 2016HT13549
Dissertation work carried out at
Veveo India Pvt Ltd (Sub of TiVo Corp), Bangalore

November 2018

Automating the Testing of Mobile Application
BITS ZG628T: Dissertation
ID No. 2016HT13549
Dissertation work carried out at
Veveo India Pvt Ltd (Sub of TiVo Corp), Bangalore

Submitted in partial fulfillment of M.Tech. Software Systems degree programmeUnder the Supervision of
Vikram Makam Gupta, Sr. Engineering Manager, Veveo India Pvt Ltd, (Sub of TiVo Corp), Bangalore

November, 2018

Birla Institute of Technology & Science, PilaniWork-Integrated Learning Programmes Division
First Semester 2018-2019
BITS ZG628T: Dissertation

BITS ID No. : 2016HT13549
EMAIL ADDRESS : [email protected]’S EMPLOYING : Veveo India Pvt Ltd, (Sub of TiVo Corp), Bangalore
SUPERVISOR’S EMPLOYING : Veveo India Pvt Ltd, (Sub of TiVo Corp), Bangalore

This project is outcome of sound knowledge gained during completion of Master of Technology course at Birla Institute of Technology and Science, Pilani.
I am using this opportunity to convey my thankfulness to everyone who supported me throughout the course of this project. I am thankful for their support and guidance and friendly advice during the project work. I am sincerely grateful to them for sharing their knowledge and illuminating views towards completion of the project
I express my warm thanks to Vikram Gupta and Vishwas S P for their support and guidance at VEVEO INDIA PVT LTD (sub of TiVO CORP), Bangalore.
I would also like to thank my project external guide Prof. AVINASH GAUTAM of BITS Pilani and all the people who provided me with the facilities being required and conductive conditions for my M. Tech
Table of Contents
Certificate i
Abstract ii
Acknowledgement iv
Index of Diagrams vii
1. Introduction 1
1.1 Problem Statement    1
1.2 TiVo Mobile Application   2
2. Appium   3
2.1 Appium Architecture   3
2.1.1 Client/Server Architecture    3
2.1.2 Session4
2.1.3 Appium Server   4
2.2 How Appium works in Android  4
3. UIAutomatorViewer   5
3.1 Locating Element using UIAutomator   6
4. Page Object Model    8
4.1 Need of POM  8
4.2 Advantages of Page Object Model   8
5. Reports   9
5.1 Test Cases Pass report  9
5.2 Test Cases Fail report   10
5.3 Test Case Abort report   11
6. Summary   12
7. Conclusion  13
8. Directions for future work  14
9. References 15
10. CheckList  16
Index of Diagrams
Figure 1. Appium Architecture5
Figure 2. UIAutomatorviewer window    6
Figure 3. Node Detail Window    6
Figure 4. Locating by Resource ID   7
Figure 5. Locating by Text     7 
Figure: 6. Abort Report        9
Figure 7. Fail Report     10
Figure: 8. Abort Report     11
Problem Statement
In the highly competitive world of technology, mobile automation testing has become very important. The mobile automation testing is growing in a very rapid way as today we have more than thousands mobile devices. It is important to test the mobile apps on various devices without breaking the existing features. Using these types of mechanism one can test the features confidently without any fear.

Testing with the mobile applications has its own challenges. It is a very time consuming for manual test engineering teams to validate on so many mobile devices on each feature, OS versions, UI testing etc. So, no company can afford so many devices for feature testing and support building a wide infrastructure to test the mobile apps.

A humongous number of mobile devices this contains various OS versions, screen sizes, different resolutions, different manufacturers etcNeed of updating the app very frequently.

Different kinds of application like hybrid apps, native apps, responsive apps
Testing on different kinds of manufacturers like varying memory optimizations, CPU utilization etc.

Also, moreover the cost on playing around on all the devices is just unbearable and for any organization it will be a too much expensive.

So, for these are all the purpose, mobile automation is must and it is required to address many of the challenges on testing the mobile application development.

Page 1
TiVo Mobile Application
Our mainline stream business is to manufacture the setup boxes and providing the contents to the audience with the help of OTT services as well as cable operator. To support to the setup boxes, we developed mobile applications on Android and iOS. We provide a plethora of features like create one pass, bookmarking your favorite shows, Recording the live TV programs, Downloading the recorded content, Recommendations and suggestions etc.

TV and streaming content at hands.
Our app lets the user to watch all the shows from the cable operators. Because we have bookmarked and OnePass shows marked on your phones and tablets. Wherever the shows like if it on Live TV or it is available on Amazon, Netflix or even in HULU, VUDU etc all the shows are at your fingertips on the mobile devices
A TV guide and a remote.
There is no more searching your TV remote as we are providing the remote in your hands in the sense remote is in mobile application itself where one can control the setup box from mobile itself. Users can search for their favorite actors, films, games etc. They can browse through the Season, Episodes and movies as well.

Page 2
2. Appium
Appium is a open source automation tool developed by Sauce labs to automate the mobile apps. It supports cross-platform mobile automation testing. This makes use of JSON wire protocol internally to interact with mobile platforms using the web driver of a selenium tool.

To choose one of the best automation tools from an array of other tools like MonkeyTalk, KIF, Calabash and Frank, these tools require additional support which needs to be compiled with your application code. So, the problem may occur why because the app which you are testing may vary with the actual app you are submitting to the Appstore/play store.

One of the main functionalities of Appium is that it can written in any languages like JAVA, C#, Python, Ruby etc. without modifying the mobile application. The communication which happens between the Selenium Client libraries and the node js server is what ultimately it works with the mobile applications. Moreover, this is an open source tool and can run very efficiently on a various device and this is very apt choice for mobile automation testing.

Architecture of Appium
This software is nothing, but a http server written in node js which creates and communicates multiple Web driver sessions for various platforms like Android and iOS.

This starts with a test cases on the device which establishes a server and keep listening to the commands from the server. It always receives HTTP requests from client and it manipulates those requests in different ways which depends on the platform specific variations. So Appium does a kind of hack on the OS like iOS and Android as there are different kinds of mechanism to handle and execute the test cases on mobile devices.
2.1.1 Client/Server Architecture:
As this is a web server which exposes a REST API. It will do following actions –
It will receive connections from a client device
Always listens for the commands
Page 3
Executing those commands on a mobile device,
Sends the response with an HTTP response representing the result of the command execution.
Since it uses client-server architecture, anybody can write the test scripts in any langauge that has a HTTP CLient API. The server can be on a differnet location or a machine then the one running test script
2.1.2 Session:
Automation is always carried out in the form of a session. Clients initiate a session with a server by sending a POST sessoin request to the sever, with a JSON object know has ‘desired capabilities’ object.
2.1.3 Appium Server:
This tool is written in Node.js and it can be built and installed form the source. This client libraries supports web driver protocol. and Appium.exe are GUI wrappers around the Appium server. These files are bundled in such a way that it should always support to compile on the Appium server. It also comes with element inspection capabilities, which will help us in validating the hierarchy of app. This is very important for writing the tests.

2.2 How Appium works in Android
In android, the appium proxies commands for the UIAutomator testcases which is running on the device. This UIAutomator is nothing but the Android native’s UI Automatio framework which supports running unit testcases on the Android device under test. This internally uses JAVA programming language but Appium will handle and run from any webdriver supported languages.
Page 4
Fig: 1. Appium Architecture
In the above diagram we can see, here we have Bootstrap.jar file which represents test case when compiled in java. As this jar fie gets launched it establishes a connection to a TCP server. This TCP server resides inside the device and interacts with the Appium process which is nothing but the client.

3. UIAutomatorViewer
This is nothing but the GUI tool to check the UI components of the android application. This tool helps in getting the inspect elements from the layout hierarchy and can view the properties of the individual UI components. So testers can use this information in the test scripts and perform automation based on these elements.
Main key features of this tool are:
Supporting of API for cross-app UI testing.

A graphical interface to view the layout hierarchy
It can retrieve state information using the API’s and perform operations on the device under test
Page 5
3.1 Locating Element using UIAutomatorSnapshot of the TiVo app in the uiautomatorviewer window.

Fig: 2. UIAutomatorviewer window
Left is the screenshot of the Android application of the UI Automator window with all the detail information of the specific screens. Right side is the layout hierarchy and bottom of the screen is the information related to properties of the web elements.

Clicking on any element on the screen, one can look at the right side of hierarchial detail. It displays all the information of elements in tree structure.
Fig: 3. Node Detail Window
Page 6
Clicking on the WTW Menu button to display all of it’s properties.

Fig: 4. Locating by Resource ID
In this resource-id is visible, which can be used to identify element.

 Click on Guide by text to display all of it’s properties.

Fig: 5. Locating by Text
In the above screenshot, text value is visible and that can be used to identify the element.

Page 7
4. Page Object Model 
This is the most popular design pattern for automating the application for test. A page object is nothing, but a class designed for having all the object related to only that particular page objects.
When testers write the test scripts. these methods of page object class is used/invoked to interact with web elements of that page. The main benefit on this framework is, if in future UI elements gets changed then testers don’t need to change the test case scripts, instead only the page objects of the class can be changed.

4.1 Need of POM
It is always a tedious process to maintain the test coverage as and when it increases. This is result in unmaintainable project structure if locators are not properly managed. This type of risks can happen due to many reasons like duplication of code or may be locators as well.

Eg: In the Home screen of the mobile application we have title of the page which is on the top-left side of the screen. So, while writing the test scripts it is validating on the title on the top-left side with a specific locator. Now images UI has changed or revamped, and the titles is moved to the center of the screen. So, while performing the automation, test scripts fail due to the locators not found. So now testers should go through whole code to identify the locators and update to the new locators. This is very time-consuming process and every time locators are changing it will become very difficult to the maintain the code.

4.2 Advantages of Page Object Model:
According to this framework, locators and test scripts should always keep separately so that it will be easy for to maintain and develop the test case very quickly.

This is type of approach makes automation engineer very friendly and fast execution.

Test scripts can be made as short as possible and optimized as we will be reusing the methods from the page object classes.

If there is a change in the UI, then it can easily modify and implemented without any hurdle
Page 8
5. Reports
Reports are always important in analysing the performance and taking decisions quicker. It is the only evidence for the work we have always done. In our project I have implemented a mechanism where the framework will capture step by step execution flow, taking the screenshots of failed testcases, for each testscrits capturing the logs, adding various colors for identification the pass, fail, abort testcases..5.1 Test Cases Pass report:

Page 9
5.2 Test Cases Fail report:

Fig: 7. Fail Report
Page 10
5.3 Test Case Abort report

Fig: 8. Abort Report
Page 11
6. Summary
In this project, we have learnt the how Appium can be used to automate the mobile applications testing when compared to old tools like QTP. We have also learnt and implemented very popular framework – POM (Page object model) against the old frameworks like Linear Scripting framework.
This project also allowed to learn about Android UI architecture – UI Automator where we can do the UI testing of the mobile applications. With the help of this we have learnt different techniques of finding the Web Element and interacting with UI elements
Complete report generation of this project needs many integration tools like Bugzilla, QTest, TestMaster, Jenkins (which is confidential as it is used by many projects in the company and hence this is never discussed anywhere in the project) and it will be the enhancement for this project

Page 12
7. Conclusion
In this Project, I covered different topics for a deeper insight into Appium. I learned about how Appium works and the importance of Automation, and I gained a deep insight into Android UIAutomator architecture and the different methods of getting the Web Element.
I also learned what hooks are and how to use them. I learned the different ways of running Mobile applications through this Automation framework. I also learned how to look up an Android package name and find out different activities for an app. This is needed when we want to launch the Appium session on a pre-existing app on an Android device.
I also learned how important is to generate the reports and sharing it to the stake holders. This was one of the very important tasks as it classifies the issues and helps the management to take the decision at the earliest for the deliverables.

Using this POM, we also generated the report in the HTML format with the integration of internal tools like QTest (Confidential). Now anybody can see this report and can make the decision quicker about the stability of the builds.

Page 13
8. Directions for future work
As part of this dissertation work, we focused on Automating the mobile application only android with the help of Appium software. But we can have changes and improvements on top to this work to enhance the automation on iOS devices as well.

Creating automated test cases for regression test cases of Android as currently its being tested manually only.

Enhancement of the test framework to adjust the new features of application
Creating automated test cases for Sanity Testing of iOS as currently its being tested manually only.

Development of a diagnostics feature which will help to compare the data coming from the server (in raw JSON format) to the data which is actually being displayed in the app is in progress. Development of this feature is totally based on concepts of android development
Page 14
9. References
1 Dawn Griffiths, David Griffiths. “Head First Android Development: A Brain-Friendly Guide”, 2016.

2 Nishant Verma. Mobile Test Automation with Appium”, 2017
3 Manoj Hans. “Appium Essentials”, 2015
4 https://www.toolqa.com5
Page 15
10. CheckList
Page 16