DevOps Certification Training
- 49k Enrolled Learners
- Live Class
Appium has seen widespread acceptance in the mobile application testing industry. Testing as a discipline has garnered great importance in today’s world so that enterprise-level applications can be delivered. This has led to the demand for professionals well versed with Appium. None the less, this blog is aimed to prep you up for questions you might face in a job interview related to Appium!
Below you will find 50 different Appium Interview Questions, that have been classified into:
Mobile Application Testing (MAT) is the testing of an application on mobile devices and it is different from Mobile Testing (MT) in the term that, in MT we focus on the native application features of the Mobile devices like Call, SMS, Media Player, etc. Meanwhile, in MAT we focus only on the functionality & features of the application under Test.
Emulation is the process of mimicking the outwardly observable behavior to match an existing target. The internal state of the emulation mechanism does not have to accurately reflect the internal state of the target which it is emulating.
Simulation, on the other hand, involves modeling the underlying state of the target. The end result of a good simulation is that the simulation model will emulate the target which it is simulating.
Ideally, you should be able to look into the simulation and observe properties that you would also see if you looked into the original target. In practice, there are some shortcuts to the simulation for performance reasons — that is, some internal aspects of the simulation may actually be an emulation.
Mobile application testing framework includes three segments:
Application Package: It is the target application that requires to be tested.
Instrumentation TestRunner: It is a test case runner that runs test cases on the target application. It includes an SDK tool for building test and a tool that provides APIs for writing a program that controls an Android device, for example, MonkeyRunner.
Test Package: It includes two classes, Test case classes, and Mock objects. Test case classes include test methods to perform on the target application, while the mock object includes mock data that will be used as sample input for test cases.
Mobile applications can be broadly categorized into three categories i.e, Native app, Web app and Hybrid App.
Native App: Native app is developed specifically for one platform, which is coded with a specific programming language (like Objective C for iOS, Java for Android) and installed directly onto the device and can take full advantage of all the device features. Native apps can use the device’s notification system and can work offline. Native apps are installed through an application store (such as Google Play or Apple’s App Store). Native mobile apps provide fast performance and a high degree of reliability. Example of native apps: Temple Run, Candy Crush, etc.
Web App: Web applications are mobile web portals that are designed, customized and hosted specifically for mobiles. They are accessed through the mobile device’s web browser using a URL. Web apps became really popular when HTML5 came around and people realized that they can obtain native-like functionality in the browser. Mobile web applications cannot use device functionality. Example of web app: google.com, m.snapdeal.com, m.yahoo.com, etc.
Appium is based on Selenium which is an HTTP protocol by Google designed to automate browsers. The idea is actually very nice as automating an app (especially a webview-based one) is not so different (in terms of required APIs) from automating a browser.
Appium is an open source, cross-platform automation testing tool. It is used for automating test cases for native, hybrid and web applications. The tool has a major focus on both Android and iOS apps and was only restricted to the mobile application testing domain. Recently, a few updates back, Appium also announced that they will support the testing of desktop applications for windows. Appium is developed and maintained by Sauce Labs. Currently, Appium version 1.10 is being distributed. Appium first started off as a command line based testing service that can be installed using Node.js. In their latest release, named ‘Appium desktop’ they have released a robust and refined tool with an intuitive graphical user interface.
Appium abilities are:
Appium is not a huge application and requires very little memory. Its architecture is actually pretty simple and light as Appium acts like a proxy between your test machine and each platform automation toolkit. Once up and running, Appium will listen to HTTP requests from your tests. When a new session is created, a component in Appium’s Node.js code called _proxy_ will forward these Selenium commands to active platform drivers.
In the case of Android, for example, Appium will forward incoming commands to the [chromedriver] (90% of cases, Appium will not even change commands while routing them), this happens because ChromeDriver supports WebDriver and Selenium. For this reason, Appium will not allocate much memory itself, you will see a lot of memory being allocated by other processes like [adb], ChromeDriver or the iOS automation toolkit (called by Appium while testing and automating).
When it comes to testing, especially webview-based apps, there are a lot of scenarios that can be tested also depending on the feature coverage you want to ensure. Appium is pretty handy for testing scenarios that users will go through when using your app.
But, if you need to test more than UX simple interactions, then Appium will become a limitation. Think about features like keyboarding. It is not so easy when complex touch/keyboard mixed scenarios are involved, the probability of a false failure is high; do not misunderstand me on this: I am not saying it is impossible to do, just not so easy as you might think!
Another little nightmare with Appium is exchanging data. When your test needs to exchange data with your app (especially in the incoming direction), you will need to play some tricks. So always consider that sending and receiving information is not that straightforward. It is not Appium’s fault, the WebDriver specification was designed for automating stuff, not exchanging data!
Generally, the issue depends upon the different OS/device version. It might be that the same application is working on one OS while it might not work on another version. For example, we faced an issue that our application was working fine on iOS 6.x version devices but on tapping a few modules on iOS 5.x devices application crashes and the same happened with 2.3.5 Vs.
Unfortunately, there is no magic formula to translate your tests into Selenium tests. If you developed a test framework on different layers and observed good programming principles, you should be able to act on some components in your tests in order to migrate your suites to Appium.
Your current tests are going to be easy to migrate if they are already using an automation framework or something close to a command-based interaction. Truth be told, you will probably need to write your tests from the beginning.
Major areas are
Also, if your application is accessing any network then you must check the logs generated during that period so that the sensitive information should always go in an encrypted form.
We generally do regression testing of a relative module and mainly focus on the area which is related to the bug fixes as per the developer. This is because we cannot perform complete regression testing in a very short span of time. So, we just perform sanity tests on the rest of the application, but only for high priority devices. High priority devices are systems that are running the latest versions of the operating system.
The very first test we have to perform is installation. After that, we check the basic functionality and following which, we check the connectivity of the application with its peripherals. Then we uninstall the build and verify how the application responds when we interrupt it during installation. We also check interruption scenarios when our application requests a network call.
We also perform low network/poor connectivity testing during a network call. The process of upgrading from an older version to a newer version is also tested. Navigation in the application without a network is an important feature that is tested in general testing. Also, the compatibility of the app on different kinds of phones is a major criterion in general testing.
Of course, it depends on the test. If your test simply runs a scenario, it will take as many commands as the number of interactions needed to be performed (thus very few lines). If you are trying to exchange data, then your test will take more time for sure and the test will also become difficult to read.
Appium does not support test frameworks because there is no need to support them. You can use Appium with all sorts of testing frameworks. NUnit and .NET Unit Test Framework are just a few examples. You will write your tests using one of the drivers for Appium, thus your tests will interface with Appium just in terms of an external dependency.
When I say “data exchange” I am not referring to scenarios like getting or setting the value of a textbox or an elements attribute. All these things are easy to achieve in Appium as Selenium provides commands just for those. By “data exchange” I mean exchanging information hosted by complex objects stored in different parts of your webview-based app like the window object.
Consider the scenario when you dispatch and capture events. Your app can possibly perform many functions and the way the flow of data can be handled are many. Some objects might also have a state and the state machine behind some scenarios in your app can be large and articulated. For all these reasons you might experience problems when testing.
The following are the features and benefits of Quick Test Pro:
If you think about it, what really is required from is the test script. The fact that you must deploy an Appium server somewhere is just an extra feature. If you want to skip this part, you can rely on some web services that have already deployed a whole architecture of Appium servers for your tests. Most of them are online labs and they support Selenium and Appium. In this way, you don’t spend exorbitant amounts of money and you also don’t invest time and effort on new infrastructure.
For writing Appium tests you require:
The risks of Automation Testing are:
For older versions of Android, Appium might not be supported. For instance, Appium is only supported for Android versions 4.4 or later for Mobile Web Application tests, Android versions 2.3, 4.0 and later for Mobile Native Application and Mobile Hybrid Application tests.
For those versions in which Appium is not supported, you can request an emulator driven by Webdriver and Selendroid. All you need to do is, use the Platforms Configurator and select Selenium for the API instead of Appium. In the Sauce Labs test, you will notice that the top of the emulator says “AndroidDriver Webview App”. In addition, you will notice that you will get a “Selenium Log” tab which has the output of the Selendroid driver.
With an emulator driven by Webdriver & Selendroid, you will be able to test Mobile Web Application only. You should be able to select any Android emulator version from 4.0 to the latest version and any Android emulator skin (e.g “deviceName”: “Samsung Galaxy Tab 3 Emulator”).
For older versions of iOS, Appium might not be supported. For instance, Appium supports foriOS versions 6.1 and later. For earlier versions of iOS, the tool or driver used to drive your mobile applications automated test is called iWebdriver.
To obtain a simulator driven by iWebdriver use the Platforms Configurator and select Selenium for the API instead of Appium. With an emulator driven by iWebdriver, you will be able to test Mobile Web Application only. In addition, in the Sauce Labs test, you will notice a “Selenium Log” tab which has the output of iWebdriver.
Filters help you in finding relevant information about your application and you can create a filter based on the application package name like com.abc.com. You can save this filter by any name. When you click on this filter, you will see only those logs which are from your application.
You can create a filter based on log tag which is related to a particular line of code, for example, if you have placed system.out to print the output then you can create a filter by a tag System.out. Then it will shortlist all the print output in the code. You can create a filter by Choreographer which helps in finding the skipped frames if you want to see them. You can create filters corresponding to your PID and log message.
For mobile testing, the test automation tool should have the following criteria
Challenges that a tester faces while performing mobile testing are:
It’s one of the most commonly asked Appium interview questions. You’ve to be a little logical and practical while answering it. Don’t just simply answer “It would depend on what you need.”, because it would be a layman answer which interviewer won’t expect from you. Rather you should explain it by an example. You can answer by saying that it’s always best to test on real devices. As it would allow you to catch errors that you may not detect otherwise, but, you have to configure the device smartly with the Appium server so that it can detect the device. Sometimes the ADB(Android Debug Bridge) may disconnect from the device even if it remains plugged in, and it can cause your tests to fail. To handle such issues, you can write a module which resets the ADB after some time to re-connect to the devices.
It is similar to the Selenium IDE plugin and enables the record and playback support in Appium. It captures the moves of a native application by inspecting DOM and produces the test scripts in any desired language. However, Appium Inspector does not support Windows and uses the <UIAutomator> viewer.
The following are the errors you might observe with Appium.
There are a number of Selenium commands that work with Appium tool.
You can test the interrupts like
For performance testing of web services, you can use JMeter. It is an open source tool which can be used to test the API’s performances.
For automation, there are several paid tools available in the market like SeeTest, Ranorex, Silk Mobile etc while free automation tools are Calabash, Appium, Robotium for Android, KIF for iOS.
We generally use logs to see the cause of the issue, where the failure is occurring. So for iOS – iPhone configuration utility & for Android Monitor.bat, etc can be used. If you provide logs from these tools to the developer, they can easily understand the cause of the issue.
Mobile security testing includes
Designing the tools and tests to run software takes a lot of manual, human effort, though there are frameworks and tests ready-made for engineers to use. Even with automated testing, human error is still a factor – tools can be buggy, inefficient, costly, and sometimes even technologically limited in what kinds of tests they can run on their own.
The first step is to segregate the different test cases that are to be automated. Following this, you must prepare test data as per the needs of the test cases. Reusable functions need to be written which are frequently used in those test cases. Later test scripts are prepared by using reusable functions and applying loops and conditions wherever necessary.
Open source tools are free to use frameworks and applications. Engineers build the tool and have the source code available for free on the internet for other engineers to use.
Vendor tools are developed by companies that come with licenses to use, and often cost money. Since they are developed by an outside source, technical support is often available for use. Example vendor tools include WinRunner, SilkTest, Rational Robot, QA Director, QTP, LR, QC, RFT, and RPT.
An In-house tool is a tool that a company builds for its own use, rather than purchasing vendor tools or using open source tools.
No. Proper automation requires as little intervention from humans as possible since the tools used are built to run tests once they are set up. As convenient as this might be, it should not be a complete replacement for manual testing – only for repetitive tasks like load testing, where thousands of virtual users are required. Engineers should not automate things like test scripts if those scripts can only be expected to run occasionally, nor should they automate code reviews, or bug testing for new builds of software that might require human interaction to detect issues. We can conclude by saying that large-scale, repetitive tasks are a better fit for automation.
During the planning phase of automation, the points to be considered are as follows:
So, this brings us to the end of the Appium Interview Questions blog. I hope this set of Appium Interview Questions will help you ace your job interviews. All the best for your interviews! Apart from this Appium Interview Questions Blog, if you want to get trained from professionals on this technology, you can opt for structured training from edureka!
If you have any questions or doubts, you could leave a comment in the comment section of this Appium Interview Questions blog, and we will get back to you as soon as possible.