Appium Interview Questions and Answers | Mobile Testing Interview Questions and Answers | Edureka

[Music] hi guys my name is Aria and I welcome you all to this appium interview questions video so in this video we will be tackling some questions that you might face yourself while giving an interview regarding any job that might use appium from its day-to-day curriculum so when you are applying for the job that uses a film that means you are also applying for a job that is mostly related to mobile application testing automation testing and appium as a whole okay so most of our questions will be related to application testing moreover the mobile part and automation testing and some few appium specific questions - okay so we have 50 questions to go down so let's get into our video without wasting much time today so our first question of the day is what is mobile application testing and how is it different from mobile testing okay so to tackle this question particularly you could answer in the following way well mobile application testing or m80 as you might call it is the testing of application on mobile devices and it is different from mobile testing in the term that we focus on the native application features of the mobile devices like calls SMS media players etc violin mobile application testing we focus only on the functionality and the features of applications under the test that is mobile testing is generally done by handset makers like Samsung as she sees Nokia Sony Apple etc while mobile application testing is carried out by various product based companies and through their vendor like services based companies which do testing of various mobile application products on different devices like Gmail or mobile Skype on mobile etc okay time for the next question and that is explain the differences between an emulator and a simulator well this is more the more important questions when it comes to a testing based interview so pay attention properly so emulation is a process of mimicking the outwardly observable behavior to match an existing target the internal state of the emulation mechanism have to accurately reflect the internal state of the target which it is emulating following which simulation on the other hand involves modeling the underlying state of the target the end result of the 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 may be some shortcuts to the simulation for performance reasons and that is some internal aspects of the simulation that may actually be an emulation moving forward with our list of questions is question number three and that is list out the type of mobile application testing so the type of mobile app testings include usability testing compatibility testing interface testing service testing low-level resource testing performance testing operational testing installation tests and security testing moving on our next question is can you explain the general structure of mobile application testing frameworks now this again is a very common questions in testing based interviews so let's go ahead and see the answer so mobile application testing frameworks include three segments so the first segment is called the application package now it is the target application that requires to be tested second is the instrumentation test Runner it is a test case runner that runs test cases on a target application it includes an SDK tool for building tests and tool that provides API is for writing programs that control an Android device an example would be monkey runner the third part that makes up a structure of a mobile application testing framework is a test package so this includes two classes one is the test case classes and the other the mock objects test case classes include test methods to perform on target applications while mock objects include mock data that will be used as sample input for test cases okay moving on to question number five is mention what are the common bugs found while mobile application testing so there are four kinds of common bugs that are actually found while mobile application testing those are critical bugs block bugs major bugs and minor bugs so critical bugs are the ones that make your phone system crashed when testing particular features on your device block bugs on the other and render your phone useless unless you until you reboot your device major bugs include perform a function of a particular feature minor bugs mostly include gy failure bugs okay now let's quickly move on to question number 6 and that is the full form of rails application extensions ok so this is one of the easier questions and this should be a clear winner so IPA stands for iOS apps your package on the other hand apk is stands for Android application package file then we have exe files - so exe stands for executable file now other than these three we also have two more that you can mention that is jad which stands for java application descriptor and PRC which stands for farm resource compiler moving on to question number seven and that is the types of mobile application that you might find today so basically you have to explain the different types of mobile applications in this question now this is a fairly long answer so let's tackle that first so mobile applications can be broadly categorized into three categories that is native applications web applications and hybrid applications so let's take a look at what native applications can do first so native applications are developed specifically for one platform which is coded with a specific programming language for example objective-c for iOS and Java for Android and they are installed directly onto the device and can take full advantage of all the device features for example they can use the camera the GPS the accelerometer the compass the phone book etc native apps can use the devices notification system and they can also work offline native apps are installed through an application store for example the Google Play Store or Apple's App Store native mobile apps provide fast performance and a high degree of reliability examples of native apps include games like temple run candy crush etc the next kind of app is a web app so web applications are mobile web portals that are designed customized and host it specifically for mobiles they are accessed through the mobile devices web browsers using a URL web apps became really popular when html5 came around and people realize that they can obtain native-like functionality in the browser now mobile web applications cannot use device functionality and examples of mobile web infuse google.com MDOT snob real calm and m.com above that we have hybrid ups now hybrid apps are basically web apps that are embedded in a native app and run on the device and are written with web technologies for example html5 CSS and JavaScript hybrid apps run inside a native container and leverage the devices browser engine but not the browser itself to render the HTML and process the JavaScript locally a web to native abstraction layer enables access to device capabilities that are not accessible in mobile web applications such as the accelerometer camera and the local storage a hybrid app is not tied to any platform or any particular mobile device so it can run on any device once written and built basically it follows the right ones and run everywhere protocol examples of hybrid app include flip card Facebook and Twitter moving on to our next question is what exactly is appium so 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.1 1 is being distributed and a fin first started off as a command-line based testing service that can be installed using node GS in their latest release named a PM desktop they have released a robust and refined tool with an intuitive graphical user interface FM desktop comes with an application element inspector and we will see the uses of these in later questions okay it's time for question number 9 and this question is what is a PM's philosophy now appens philosophy can be actually divided into four points so let me just list them down for you so you shouldn't have to recompile your app or modify it in any way in order to automate it secondly you shouldn't be locked into a specific language or framework to write and run your tests third a mobile automation framework shouldn't reinvent the wheel when it comes to automation API is last but not the least a mobile art framework should be open-source in spirit and practice as well as in name okay now it's time for question number 10 and this one is an opinion based question so our question is what is a PM strongest point in your opinion so in this type of question whatever your opinion may be always give good reasons for it for example let me just answer this for you so a PM 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 api's from automating a browser appium is also designed to encourage a two-tier architecture a machine runs the test written in one language and another one actually executes sit for the more the webdriver protocol targets scalability and this makes up him very scalable as well remember that you will need to write your test once and a film will be in charge of executing it in all platforms so basically the two-tier architecture makes appium a very lightweight and very functional tool and that in my point is appium strongest point our next question for today is is there any advantage of using appium on sauce labs server well yes there are a bunch of advantages of using a pieman sauce lab server for one you save the time it takes to set up the appium server locally secondly you don't have to install configure the mobile emulators or simulators in your local environment thirdly you don't have to make any modification to the source code of your application and fourth you can start scaling your tests almost instantly okay it's time for question number 12 and that is list out the appium abilities or the appium features so the appium abilities are features as you might like to call it are as follows so firstly appium is a cross-platform tool for native and hybrid mobile automation solutions secondly appium uses the Jason wire protocol thirdly appium does not require any fee compilation of the app that is going to be tested appium supports automation tests on both physical devices as well as simulators and emulators okay it's time for next question and that is question number 13 and that is what is your opinion on the performance of appium well avium is not a huge application and requires very little memory its architecture is actually pretty simple and light as appium acts like proxy between your test machine and each platform automation toolkit once up and running often will listen to HTTP requests from your tests when a new session is created a confident in IBM's node.js code called proxy will forward the selenium commands to active platform drivers in the case of Android for example a female forward incoming command to the chrome driver 90% of the cases often will not even change the commands while driving them and this happens because chrome driver supports webdriver and selenium for this reason often will not allocate much memory to itself and serve as a very lightweight tool but you will see a lot of memory being allocated by other processes like ADB chrome driver or the iOS automation toolkit which are processes that are called by appium itself while testing an automating moving forward is question number 14 and that is list out the limitations of using appium well just like any other software there are a few limitations to using appium firstly a film does not support testing of android versions lower than 4.2 secondly limited supports for hybrid app testing example it is not possible to test the switching action of applications from the web app to native and vice versa thirdly there is no support to run appium inspector on Microsoft Windows last but not the least parallel test executions on mark devices require multiple machines ok so time for question number 15 and that is do you need a server machine to run tests on a PIM well the answer to that is a very easy gnome while a fem promotes the two-tier architecture where a test machine connects to a test server running a fem and automating the whole thing however this configuration is not mandatory and you can have a fem running on the same machine where your test runs instead of connecting to a remote host your tests will connect to a VM using the loopback address okay it's time for question number 16 so that is what type of tests are suitable for appium so 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 at user we'll go through when using your app but if you need to test more than ui/ux and simple interactions then appium will become kind of a limitation think about features like keyboarding it is not so easy when complex touch or keyboard mix scenarios are involved and the probability of a false failure is pretty high so 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 a pimps fault the webdriver specification was designed for automating stuff and not exchanging data ok moving on to question number 17 and that is list some issues faced with cross-platform testing well generally the issue depends upon the different OS and device versions and it might be something that is working on one OS while it might be not working on another version a common example that can be faced is that an app might work on iOS 6.0 X version devices but on tapping few modules on iOS 5.0 X device applications the application kind of crashes and the same happens with iOS 4 2 3 and 1 now it's time for question number 18 and that is explain the design concepts of a theme so appium is an HTTP server written using node GS platform and drives iOS and Android sessions using webdriver JSON wire protocol hence before initializing the appium server no GS must be pre-installed on the system when appium is downloaded and installed then a server is set up on our machine that exposes a REST API it receives connections and command requests from the client and execute that command on mobile devices of that it responds back with HTTP responses again to execute this request it uses the mobile test automation framework to drive the user interface of the Apps frameworks like apples instruments for iOS which is instruments are available on in xcode 3.0 or later with OS X version 10.5 and later then there's google's UI Automator for Android API level 16 or higher and selendroid for API levels 15 or less okay this brings us to question number 19 and that is I already have a platform specific test for my app so what should I do to migrate to app him well this is a scenario based question and questions like these can be actually manipulated but the answer remains the same so if anybody is trying to ask you how you can migrate to appium this is what you should answer unfortunately there is no such magic formula you translate your tests into selenium tests if you develop the test framework on different layers and observe good programming principles you should be able to act on some components in your tests in order to migrate your suits to up in your current tests are going to be easy to migrate if they are already using an automation framework for something throws to a command based interaction should being told you will be probably needing to write your tests from the beginning but what you can do is you can reuse your existing components okay so time for question number 20 and that is what are the main criteria on the consideration mint performing end-to-end testing now the major areas are installation first time launching applications without having network an installation of app orientation of app that is if it supports it testing application performance on different kind of devices and network scenarios testing the application response and how it is responding when invalid user credentials are provided and to try to change them after installation and so on also if your application is accessing networks then you must see the logs generated during that period so that sense of information should always go in encrypted form like if it is payments related with credit card numbers etc okay time for question number 21 and that is how do you test patches and defects and fixes intended for an app already in production well we generally do regression of relative modules and mainly focus on the area which are related to bug fixes as both the developer as we can not do entire regressions in very short span of time so just to sanity of rest of the application modules on high-priority devices on which you have major customer base if you have crunch of time numbers and if theme size is not an issue do sanity on all major devices moving on to question number 22 and that is what kind of testing would you perform for a general application this is a very generic question so we are going to have a very generic answer so firstly you could say the very first test we have to perform is installation and after that we check the basic functionality and after that we check the connectivity related stuff of the application then we uninstalled the build and verify how applications respond when interrupts during installations are occurring and also we check interruption scenarios and our application requests a network call we also do a low network and poor connectivity testing during network call and upgrade from older versions to newer versions navigation in the application with our network if it supports this feature and compatibility of application on different kind of phones like having external buttons and devices that do not have external buttons and some stuff like flip phone slider phones etc moving on a question number 23 and that is how much time does it take to write a test in appium of course it depends by the test if your test simply runs the scenario it will take as many commands as the number of interactions needed to be performed thus very few lines and if you are trying to exchange data then your test will make more time for sure and the test will also become difficult to read moving on a question number 24 and that is what test frameworks are supported by a PIM well a PIM does not support test frameworks because there is no need to support them you can use a pin with all test frameworks you want example n unit and dotnet unit you will write your tests using one of the drivers for appium thus your tests will interface with appium just in terms of what awful the external dependencies are so use whatever test framework you want moving on we have question number 25 and that is what is data exchange now when I say data exchange I am NOT referring to scenarios like getting or setting the values of textbox I am also not referring to getting or setting the values of an element's attributes all these things are easy to achieve in appium as selenium provides commands just for those my data exchange I mean exchanging information hosted by complex objects stored in parts of your web view based app for example the window object now consider when you dispatch in capture events your app possibly do many things and the way data flows can be handled are many too now some objects might also have a state and the state machine behind some scenarios in app can be large an articulated for all these reasons you might experience problems when testing okay now moving on a question number 26 is another question and this question is kind of uncommon but I've still added it because I think it is pretty important so this question is what are the features and benefits of quick test Pro so the following are the features and benefits of quick test Pro well firstly it is a keyword-driven testing it is suitable for web-based application for both client and server it has better error handling mechanism the data driven testing features are pretty excellent it has record and play features the screenshots can be recorded and runtime data table can be used for persisting values moving on to question number 27 is another scenario based question so this can be framed in various fields so the first way is as you guys see on your screen and that is can appium help me cut costs another way this question can be asked is I don't want to set up a whole infrastructure for my tests and I don't want to spend money on hardware so how can have them help me here well if you think about it what really is required from you is writing tests when the fact that you must deploy an app in server somewhere is something more if you want to skip this part you can rely on some web services that already deployed a whole architecture of appium servers for your tests most of them are online labs and they support selenium and appium so the combination of server based testing along with online laboratories will obviously help you cut costs along many Connells and the question that is commonly asked is is debugging appium difficult now the answer to that is are very easy no appium is a node.js application so it is JavaScript in the essence the code is available on github and can be downloaded in a few seconds as it is small and not so complex depending on what you have to debug you will probably need to go in deeper in your debugging experience however there are some key points where setting a breakpoint is always worthy for example the proxy component is a lower dimension moving on to question number 29 is mentioned what are the basic requirements for writing appium tests so for writing a pin tests you require some few basic things so firstly is the driver client now rpm drives mobile applications as though it were a user using a client library you write your appium tests which wrap your test steps and send them to the RM server over HTTP protocols in the second requirement is an app iam session you have to first initialize a session as such a pin test takes place in the session once the automation is done for one session it can be ended and wait for another session the third one is desired capabilities now to initialize an RPM session you need to define certain parameters known as desired capabilities like platform name platform version device name and so on it specifies the kind of automation one requires from the appium server last but not least we need the driver commands and you can write your test steps using a large and expressive vocabulary of commands okay so it's time we move on with our video so our next question now is what are the risks associated in automation testing so the risks of automation testings are as follows first questions you might ask is do you have skilled resources the automation testing demands resources with some knowledge about programming focus on the resources identify whether the resources are proper knowledge for automation testing are they capable to adapt easily to the new technologies these measures are to be well assessed for building an automation testing team second thing that you might have as a risk is the initial cost for automation is high initial cost for automation is too high for initial setup and it includes automated tool purchasing training ad maintenance and of the test scripts and sometimes the unsatisfied customer base is high for automation testing and their products it should be ensured that the cost compensates the testing results thirdly if you why is not fixed do not think about automation so prior to automating the user interface it should be strongly determined that the UI is not changing extensively lastly you have to make sure that the application is stable enough so to automate the early development cycle unless or otherwise it is agile environment would not be a good idea it costs script maintenance cost very high last but not least you also have stopping and stop automating the tests which run once ensure that certain test cases might be running once and not included in regression testing avoid automating such test modules moving on to question number 31 is how can I run Android tests without appium so for older versions of Android app it might not be supported for instance rpm is only supported in Android version 4.4 or latter for mobile web application tests and Android version 2.3 and 4.0 and later for mobile native applications and mobile hybrid application tests for those versions in which a fem is not supported you can request an emulator driven by webdriver + SIL Android all you need to do is use our platform for an figure 8 er and select selenium for the API instead of a theme in the sauce labs test you will notice that the top of the emulator sells android drive overview app in addition you will notice that you will get a selenium log tab which has the output of the solenoid driver with an emulator driven by webdriver plus solenoid you will be able to test mobile web applications only you should be able to select any Android emulator versions from 4.0 to the latest version and any Android emulator skin so another question along similar lines is how can I run iOS test cases without appium so for older versions of iOS app you might not be supported for instance appium is supported in iOS version 6.1 and later for earlier versions of iOS the tool or driver used to drive a mobile application automation test is called the iWeb driver to obtain a simulator driven by iWeb driver you could use the platform's configure data and select selenium for the API instead of appium with an emulator driven by iWeb driver you will be able to test mobile web applications only and in addition in the sauce lab tests you will be noticing a selenium lock thumb which has the output of the iWeb driver moving on to question number 33 and that is can you elaborate on filters you may create men checking logs so firstly filters help you finding relevant information about your application and you can create filters based on the application package name like com ABC comm and save this filter by name as my application now when you click on this filter you will see only logs which are from your application now you can create filter based on log tag which is related to the things that line is doing for example if you have placed system you are out of print for printing the output then you can create a filter by the tag system dot out then it will sort out a list of all the print outputs and you can create filters by choreographer which helps in finding the skipped frames if you won't see it and you can create filters corresponding to your process ID and log message which is coming as text also moving on to question number 34 and that is mention what should be the selecting criteria for test automation tool for mobile testing so for mobile testing the test automation tool should have the following criteria firstly it should have multi-platform support it should have script usability it should be checking the jailbreak requirement also you should be checking for source code changes and the lead time for new OS version so let me just explain this one by one so multi-platform support well you have to ensure that the tool does support your current and future target platforms for script usability you can explain it by saying the object based tools provide a high degree of script usability and for jailbreak if the tool use is rooted devices it may not support latest OS versions and may be incompatible with the MDM policies above that sharing source code may not be always possible so you should look for source code changes and on the lead time part you should see how soon a tool can support new iOS Android and other OS versions because you will be testing on the latest versions of the OS a lot of the time moving on a question number 35 and that is list out the most common problems at testers faced while doing mobile testing in cloud computing so the challenge is that testers face while doing mobile testing are as follows so firstly it is a subscription model then the high costing the lock-in periods the internet connectivity issues automation is image based and time consuming and automation cannot be used outside the framework moving on is question number 36 and that is what would you prefer to test on real devices or use simulators or emulators so this is one most commonly asked questions and you have to be a little logical and practical while answering it don't just simply answer it would depend on what you need try and bring out the differences and when you are using a simulator and an emulator and you could use examples you can say something like 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 appium server so that it can detect the device sometimes the ADB or the Android debug or make this connect from the device even if it remains plugged in and it can cause your test to fail so to handle such issues you can write module which resets the ADB after some time to reconnect with the devices moving on a question number 37 and that is what is the appium inspector and what is it used for well the appium inspector is a handy tool for element discovery and event script loading I use this tool a lot whenever I'm introduced to a new app and I want to automate this tool is being maintained for OS X and Windows only currently so appium inspector is mainly used for to identify and and the element hierarchy of the app that is being tested to find the name description value and other attributes of the element and object for example a launch of activity of a certain element and to record your manual actions with the app - moving on to our next question and that is what are the probable errors you might see while working with appium well following other probable errors that you might encounter when you are working on a fem so the first one is error number one and that is missing desired capability is that example of a device named platform named l2 is you could not locate ADB and you may have missed some settings off the Android home environment variable error 3 includes stuff like selenium exceptions it indicates a failure in creating a new session error 4 is failure in locating a Dom element or determining the XPath of a certain element moving on to question number 39 is another scenario-based question so this would be something like I want to run my tests in a multi-threaded environment is there any problem with that so yes there is some Ashley problem with that you need some special care when using appium in a multi-threaded environment the problem does not really rely on the fact of using threads in your tests you can use them but you must ensure that no more than one tests run at the same time against the same appium server as I mentioned a PEM does not support multiple sessions unless you implement an additional layer on top of it to handle this case and some tests might actually fail moving on to question number 40 which brings us to the counteroffer last 10 questions and this is which selenium commands work with appium - so a bunch of selenium commands actually work with appium so these are firstly the locate command using IDs or class names then the Rays events or elements example the click function then the Flex command like the type function getting and setting in element properties command should on JavaScript and switch contacts between different webview like switching iframes in selenium webdriver and commands to manage alert boxes question number 41 is can you mention one thing which you cannot do with an emulator but you can do with real devices so you can test the interrupts like phone call message rain battery drain out completely while you were using the application on the test low battery scenarios etc on real devices other than that you can also check for memory card mounts and mounts scenarios actual performance of your application can only be tested on a real device and last but not the least Bluto related testing can only be done on real devices so the next question is question number 42 and that is what tools you use for performance testing and automation testing well this is a generic question and you can answer it in any way possible so let me just give you an example of an answer so you could say for performance testing of web services which your application uses you can use jaimito as it is an open source tool which can be used to test the aps performance notice what I did here I gave a reason for the application that I'm using just not state the application that I see or deemed to be the best for the scenario you should always give reasons for doing something in an interview for automation testing it is very subjective term and totally depends on the project needs and the type of applications there are several paid tools available in the market like C test Runner X silk mobile etc while good free automation tools are also available like calabash appium robot IAM for android ki F for iOS and using free tools you require some coding skills like Ruby or Java next is another trick question and that is what are the tools use in the debugging process so we generally use logs to see the cause of issues when failure is occurring so for iOS iPhone configuration utility and for Android monitor dot bat files are used for debugging the process so out here you'd say that no tools are actually being used but rather you use the utilities and the files or log files that you find on both devices moving the question number 44 and that is explain what this mobile security testing and it's entities include so the entities are mobile security testing as follows so firstly here to check for multi-user support without interfering with the data between them secondly checks for access to file stored in the app by any unintended users thirdly decryption or encryption methods used for sensitive data communication and last but not least the text sensitive areas in tested application so that they do not receive any malicious content let's go to question number 45 now so for question of a 45 we have chosen a rather opinionated question and that is when to choose automation testing and when manual testing so I'm gonna give a very simple answer to this sort of complicated question so firstly you can choose manual testing if the application has new functionality and the application requires testing to be only done once or twice on the other hand you can choose automation testing if the regression tests are repeated and if the testing scenario is very complex okay it's time for question number 46 and that is what are the prerequisites to start automation testing well the first step is to segregate the different test cases that are to be automated followed by preparing test data as per the needs of the test cases reusable functions need to be written which are frequently used in those test cases as later test scripts are prepared by using reusable functions and apply loops and conditions wherever necessary moving on a question number 47 is what are the disadvantages of automation testing so automation testing - comes with a few disadvantages well designing the tools and tests to run software takes a lot of manual and human effort and there are frameworks and tests ready-made for engineers to use even with automated testing human errors is still a factor as tools can be buggy inefficient costly and sometimes even technologically limited in what kind of tests they can run on their own and this moves us to the next question of the day and that is question number 48 and that is what are the differences between open-source tools mentor tools and in-house tools well open source tools are free to use our frameworks and applications engineers build the tools and have source code available for free on the internet for other engineers to use vendor tools on the other hand are developed by companies that come with license to use and often cost money because they are developed by an outside source technical support is often available for use example vendor tools include Windrunner silk this rational robot QA detector etc an in-house tool on the other hand is a tool that a company builds for their own use rather than purchasing vendor tools for using open-source tools this is generally a measure taken by companies so that they can optimize their own tool and also save a lot of money now our second last question for the day is is automation testing a complete replacement for manual we're testing well no proper automation requires as little intervention from humans as possible since the tools used are built to run tests once they're 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 be expected to run occasionally nor should they automate code review or bug testing for new builds of software that might require human interaction to detect specific issues large-scale repetitive tasks are better fit for automation and this brings us to the last question of the day and that is what are the points that are covered by the planning phase of automation well during the planning phase of automation things must be taken into consideration for example selection of the right automation tool and right automation framework list of in scope and out of scope items for automation setting up the test environment preparing Gantt charts or project timelines for test scripts and development and execution and identifying the test deliverables okay guys so this brings us to the end of our appium interview questions I hope you guys learned a lot today and I hope you guys built a little bit of confidence for your next appium interview if you have any sort of doubt you can leave them down in the comment section below and we will get back to you as soon as possible if you like this video please give it a like and a thumbs up and share this video with your friends that might be giving such interviews in the coming future I thank you guys for watching this video I'll meet you guys in the next one until then good bye I hope you have enjoyed listening to this video please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist and subscribe to any rekha channel to learn more happy learning

Channel: edureka!

Views: 28,157

Keywords: yt:cc=on, appium interview questions and answers, appium interview questions, mobile testing interview questions, appium, mobile testing, appium studio, appium interview questions for beginners, appium interview questions and answers for experienced, appium interview questions for experienced, test automation, automation testing, most popular appium interview questions, top 50 appium interview questions, software testing training, appium certification training, edureka

Id: GEo6v9JAdmo

Length: 38min 30sec (2310 seconds)

Published: Thu Apr 04 2019