Appium interview questions

Appium is a well documented open-source automation tool for executing scripts and testing native applications and hybrid applications on both Android and iOS which uses web drivers to operate. It is a very budding company that has gained many users in a short interval of time. Appium philosophy says that :

• The application which is submitted to the marketplace should be tested only.
• Writing tests in any framework and in any language which is compatible.
• Aim to build a large open-source community effort.
• A standard automation specification and API must be used.

Data exchange in Appium can be defined as exchanging information hosted by complex objects. These objects are stored in different parts of the web view application which is under testing just like a window object. Data exchange can be understood by considering a scenario in which events are dispatched and captured. The application can perform many functions and the way the data flows can also vary which can cause problems during testing.

The limitations of using Appium is given below:

• Appium does not support the testing of android which is lower than 4.2 version.
• It provides limited support during hybrid app testing.
• It does not support to run the Appium Inspector on the Microsoft Windows.

Appium commands are functions that are sent to mobile devices and available for multiple languages. Here we have listed few appium commands that are called through Java Programming language.

• Status: driver.getStatus();
• Execute Mobile Command: driver.executeScript("mobile: scroll", ImmutableMap.of("direction", "down"));
• Get device Orientation: driver.getOrientation();
• Get the current geo location: driver.location();
• Get Logs: driver.manage().logs().get("driver");

For Complete List visit (Appium API's)

There are various advantages of Apium which are as follows :

• Provides cross-platform for testing both native and web applications
• JSON wire protocol well supported
• Recompilation of application is not required
• Independent of mobile device
• The automation test is supported by Appium on a physical device and simulator as well as an emulator.
• Appium is based on Selenium which is its strongest point of this tool.
• Designed to encourage a two-tier architecture.

Appium has also a few disadvantages like :

• Cannot support older versions of Android (lower than 4.2)
• It has very little capability to locate and recognize images.
• Common gestures are yet to implement in Appium.
• Support of hybrid applications is limited

Logs are generally used for detecting the cause of the issue and to find out the reason for failure in Appium.

• For iOS, iPhone configuration utility can be used
• For Android, Monitor.bat is used for debugging.

If logs from these tools are provided, then the cause of the error can be easily found out.

A set of tools that helps in management and creating Appium packages are known as the Appium package master.

To create a package we need to use this code given below:

# using es7/babe1
Gulp create-package-and 
#regular es5
Gulp create-package ---nobabe1 –n 
The package will be generated in the out/

Mobile Application testing also commonly abbreviated as MAT is the type of testing on mobile devices and it is pretty different from mobile testing as in mobile testing, focus is on the native applications of the mobile phone i.e. call, SMS, etc and in mobile application testing the focus is only on that application which is to be tested. The functionality and features of the application which is to be tested are considered in mobile application testing and other factors are ignored.

There are numerous types of mobile application testing. Some of them are :

• Usability testing
• Compatibility testing
• Interface testing
• Security testing
• Installation testing
• Low-level resource testing
• Performance testing
• Operational testing
• Low-level resource testing
• Service testing

Common bugs that tend to appear during mobile testing are as follows :

• Critical: Crashing of the whole mobile device while testing a particular feature in the device.
• Block: Inability to do anything on the phone after testing unless the device is rebooted.
• Major: Inability to perform a function of a particular feature.
• Minor: GUI bugs fail in this type of mobile testing.

Mobile applications can be broadly classified into three main categories in today’s era which are as follows :

• Native mobile applications: The mobile apps which are developed for a particular platform and also developed with a specific programming language and are available for download in the Google Play Store for Android users and App Store for iOS users are called native applications. For example Candy Crush, tinder, etc.
• Web application: Web applications are kind of mobile web portals that are designed, prepared and customized only for mobile users. These are not available for download but are available on the web browsers of mobile phones for usage. For example m.yahoo.com, m.snapdeal.com, etc.
• Hybrid application: Hybrid applications are made by combining the best features of both native and web applications. These are the web apps that are embedded in the native app which runs on the device.

Unfortunately, there is no propaganda or medium to translate normal tests into Selenium tests i.e tests performed by Appium. Current tests can be easy to migrate if they are following a self automation process as Appium does otherwise it is a tough job to migrate to Appium. If someone already has performed specific tests, then in general views, he/she has to rewrite the code from the beginning in order to test it with Appium.

It totally depends on the test which is to be performed. If the test simply runs a scenario, it will take commands of very few lines and also very less interaction will be needed in order to test that application whereas if the test is complex and requires transfer of data it will take much more time than the previous one and also it will be a little difficult to read the lines of code of that test. 

This discussion can be concluded by saying that there is only one factor on which the time needed depends which is the complexity of the test and it is directly proportional to the time taken in Appium.

There are many risks associated with Appium testing which are as follows :

• Availability of skilled resources: Automation testing demands-resources which must be skilled and have some knowledge about programming.
• Cost of automation is high initially: The cost of automation is initially too high as it includes many things such as cost of automation tools to be purchased, training and maintenance of various test scripts.
• First, the UI has to be fixed mandatorily before automation: Before automation, it is compulsory to fix the user interface and keep a check whether the UI is changing extensively and the cost of automation and maintenance.
• Tests that have been run once should be stopped automating: To avoid ambiguity, test modules that have been run once should be stopped automating.

Appium inspector is very similar to the Selenium IDE plugin. Appium inspector has a great advantage of recording and playback support. It is basically used to capture the moves of the native application by inspecting DOS and producing test scripts in any programming language which is compatible with the user. But, the Appium inspector does not support Windows and works only viewers.

Below are some prerequisites for doing automation testing

• Firstly, the test cases that need to be automated are segregated.
• After the segregation of test cases, the test data as per the needs of the test cases is prepared.
• After that Frequently used a reusable function in test cases that need to be written.
• After that test scripts are prepared, reusable functions and loops and conditions are applied wherever necessary to prepare these test scripts.

Difference between open source tools, vendor tools and in house tools are

Open Source tools: Open source tools are those tools which are free to use frameworks and applications. It is very advantageous for the budding developers as engineers develop this tool and make it free on the internet for other engineers, developers or enthusiasts to develop and use.

Vendor tools: Vendor tools are developed by those companies which have a license to use to access their tools and codes. In these tools, technical support is available for use on the internet.

In house tools: The tool that the company builds for its own use and self-development purposes are called in house tools. They are never available for public use.

Below are a few differences between Simulator and Emulator

The issue depends on the different versions of the OS/device. Sometimes it might happen that the same application can work on one OS while it may not work on another version of OS.

For example, one issue is that one application can be working fine on iOS 6.x version devices but can crash when we use it on iOS 5.x or 2.3.5 versions.

The Basic requirement for writing the Appium test are given below:

• Driver Client: Mobile applications are being driven by Appium. We can use the client library to write our Appium tests and then it wraps our test steps and sends it to its servers over HTTP.
• Appium Session: We need to initiate this process by creating a session as such tests take place in a session. For one session, it can be ended once the automation is completed and then we need to wait for the next session.
• Desired Capabilities: Certain parameters need to be followed while creating an Appium session which is also known as desired capabilities: Platform Version, Platform Name, Device Name. It helps in the selection of which type of automation is required from the server of Appium.
• Driver Commands: We can write our test using expensive and large commands vocabulary.