Good morning, everyone. Thank you so much for joining us today. Real quick, to our presenter, Siva, would you mind going ahead and sharing your screen? We’re going to go ahead and get started here. So thanks for joining us for Getting Started with Mobile Test Automation and Appium with Saucelabs and our partner Infostretch. Our presenters today are Siva Anna who is a director of technology services from Infostretch. And Abhijit Pendyal, sales engineer at Saucelabs. Siva has more than 20 years’ experience in Fortune 1,000 companies and leads strategic engagements in Enterprise segments ranging from QA support and SAS operations, which has resulted in significant client value.
Thank you so much, Christina. And hello, everybody. Thank you so much for joining the Getting Started with Appium demo today and introduction to Appium as well. Whilst people are joining, I just wanted to touch on the value that Saucelabs provides in the Selenium and Appium ecosystem. Essentially, you may already have heard of Saucelabs. But for the ones who haven’t, Saucelabs provides the largest cloud for running Selenium and Appium tests. So if you are moving to Appium for your mobile testing needs, you can test any modality of removal application on Saucelabs as well.
One we have done in is provided close to 500 + browser and web combinations, including mobile platforms like IOS and Android. And those mobile platforms are not only emulators and simulators, but we’re also offering Android real devices. So we offer and Galaxy S4 and S4 real devices. So not only can you run a manual test for your mobile application on a mobile emulator or simulator, but you can also then extend that testing to an automated test on a real device. And of course, Siva will be going more into how Appium works and the technology behind it.
But, essentially, it’s based on the web driver protocol that Selenium is based on. And as the name suggests, the web driver protocol is essentially used to automate web browsers when it comes to Selenium. But in Appium, it now drives the underlying automation frameworks off the different mobile ecosystems out there, which is the Android and the IOS. Not only are you able to test on mobile emulators, simulators, and real devices in Saucelabs, Saucelabs offers you direct integration with any of the continuous integration tools out there.
So if you will be looking at adopting Appium as your automation framework moving forward, you will then probably look at the next step of integrating those automated tests within a CI or a CB degree pipeline, essentially, taking away the human aspect of testing and deploying to production making the most of your test flow automated, so you’re pushing to product faster. You’re testing faster and leading quality code out into the market. And how does Saucelabs make this testing easy for you? What we have done is also provide you with developing assets.
So whenever you run a test on Saucelabs, whether it’s a manual test or an automated test, you get screen shots, videos, and logs of the entire test that you run. So screen shots will capture specific element interactions that you have done with the application. The video will capture the entire screen cast of the test. And then the logs or the Appium log as well as the Sauce logs that we create for you, which can really help you in addressing failures or bugs that you may come across here in testing. And as we will see during the Saucelabs demo, we package all of these assets for you within a single URL.
So once you run a test on Sauce, and if you want to relay the results of that test to a developer or another or anybody in your team, you can just send them that particular URL and the relevant data of that particular test will be part of that single URL.
Great. So Siva is back online and ready to go. So Siva, I’m going to go ahead and make you present your signature screen. And then you can go ahead and join the line.
So hello, everyone. So thanks for covering in the meantime. So I just wanted to quickly talk about Infostretch. So Infostretch is basically software that. We work on automation as a resource that we offer to our interface clients and all clients looking for automation solutions. So in the interest of time, I’ll just kind of move into the topic that we wanted to cover. So what I want to cover are the high level kind of mobile solutions overview. So is anybody looking for getting into mobile automation or overall mobile solutions? So I want to kind of cover you with some background of what all the things that you should look for.
Then we kind of get into the Appium tool itself. I’ll give some overview of other things that are available getting into Appium automation with all the settings. Then we will do some live demo of the Appium tool itself. And then finally, I think there will be a complementary demo from Saucelabs. Abhijit will be doing a demo, the same script that I’m running for the local device how you can learn it on the cloud. So then you will be able to see how one script kind of you will be able to reuse for local execution, whether it is an emulator or the real device, then how you can leverage the cloud option that Saucelabs provides.
So to give you some background, mobile solutions, I think this is something many of you might be aware, but I think, nowadays, the applications fall in three different flavors. So one is HTML5, which is primarily a mobile web application. So you want to make sure that what automation solutions are you looking for? Support, mobile, web applications, or, in short, HTML5. Then predominantly, many applications are being developed, but now there is a shift happening. It’s kind of a mix of both HTML5 as well as hybrid. In short, it is called a hybrid. So there are some frameworks available that you can leverage to develop the application.
So this is very important to understand the different types of applications that you might be having. And you want to make sure that the mobile solutions, the QA solution, that you decide to go with supports these three platforms, whether it is an or an HTML file or the hybrid application. So what do you look for when you decide to go for a mobile or QA solution? So one is the cloud option. The cloud is becoming very, very important in any solution that you choose, especially because the. So if you have a team sending across different locations, and the cloud would allow you to leverage one set up across the different locations.
And also, especially if you want to kind of or if you’re from the cost perspective, also, if you want to leverage, for example, some of the offsite teams, you will be able to use the cloud. So you can hold the devices in US, and you can have the team working from different locations, Europe or Asian countries. You will be able to kind of leverage the cloud. So the cloud component is very important when you are looking for any mobile solutions. Then what level of automation does it support?
So whether it is supporting Selenium, or whether it is supporting UFD, or whether it is supporting any other took that you might have also. So you want to make sure the QA solution that you decide to go with supports a good level of automation and especially what kind of technologies that your team has. So you want to make sure that you have the right coverage. And then the third aspect is to make sure that what level of integrations, right. Whether it is a test management system or the continuous integration system or defect system that you might have. And you want to make sure that that solution allows you to integrate very easily. So those are the three aspects that you want to make sure they take into consideration when you are in the market to evaluate tools.
More importantly, coming down to the automation tool itself, that’s going to be one of the topics that we’ll be covering with the Appium tool is what is so specific to the automation? If I am going to evaluate an automation tool, what are all the things that I look for? One is what level of object support it provides because you want to make sure that object support is available and that it is going to be the key component for your robust automation that would help you to kind of scale across the different platforms whether it is or Android or any other systems.
So we want to make sure that the solution that you choose, the automation tool that you decide to go with supports these two platforms at least. But there are quite a few applications that do go with the Windows also. You want to make sure that you have taken enough consideration of what happens if you have the new automation on Windows also whether that tool supports that or not. Then the last two, I expect, is about strategy because you want to make sure that you are able to run a lot more on the emulator, which is going to be a lot more cheaper because you will be able to scale very easily.
And the should be able to run it on the real device, right. So how much of real happens between the script that you’ll return? Are you able to run the same script that you’ll return for emulators to the real device also, whether the real device is sitting in your desk top or it is sitting in a cloud? You want to make sure that the automation tool supports. And more importantly, how you’re able to scale because, as the number of devices or version combination increases, you want to make sure that the automation tool will be able to scale.
So that’s where I think Appium plays a big role and, along with the Saucelabs, give you the cloud and the scalability option with the very minimal infrastructure support needed from the users of the solution. So given some context, so I want to kind of dive into the actual Appium tool itself. So just to give some background of what is Appium, so Appium is one of the very popular, open source, automation tools. There are several tools where they’re, I think, kind of old and consolidated into Appium.
And nowadays, we are seeing that Appium is kind of go to choice for many of the users who are looking for open source automation tool, right. So basically, this automation in the Appium allows you to automate the three different flavors that I talked about in the beginning that you can automate. Web platform, native platform, or if you have applications written on, let’s say, CONI or Phone Gap, any framework that you might have used, you will be able to automate using Appium tool. So that’s where the real power lies that you can automate across the different technologies, different platforms.
Architecture wise, Appium is kind of a in that it integrates the Android and iWare specific technologies. So whether it is a UA automater from Android, which is the one that allows you to do the automation of the Android applications. And the instruments, which is the complementary tool from the iWare. So Appium allows you to kind of – you do not have to worry about whether it is instruments or UA automated. Appium provides one level of abstraction, and you will be able to kind of seamlessly use for both types of applications. , I think that its primary purpose is to support the older version of Android devices.
But I think, as more and more users are more into the latest version of Android, the cylinder support may not be. In terms of the platform support, so Appium does support real devices, simulators, so you can run down the local emulators or Saucelabs run emulators on the cloud. So you will be able to kind of do that. And like I said about it, it’s a hybrid and mobile web application.
To give some steps for what is it that you have to do if you want to kind of get started with the Appium, at least the three components that you would need, and one is the Appium library itself, so you can download it from the Appium website. There is a lot of information available. There is a lot of available to get started. So you should look at Appium website to get the necessary jump start. Then the other two tools are like Android Studio. It’s necessary if you want to do virtual device or emulators. So this allows you to kind of create the various emulators that you want to run for different screen sizes or different combinations of features of the emulator that you want to test.
So the Android Studio, it uses the Android SDK, which is the necessary tool for validating or running your virtual device. And the last but not least is the Eclipse Selenium or a set of components that you need because Appium, in turn, uses Selenium as the scripting language. We will go more into details. But anytime you are setting up Appium for interacting with an application, there are like three aspects. One is the application location itself. So if you want to kind of run it from your local machine and running against a real device or emulator, you have to give the path where the application is installed.
Then where do you want to launch? Whether it is an emulator – if it is an emulator, you want to use the emulator name, or if it is a real device, what is the device name? What is the iOS version, Android OS version? All of that you are to give in the second section. And the last part is more like one time set up that you are able to do to set up the Android SDK itself. So we’re going into details, but I think this is very critical that you should know for any of the applications that you are doing for iOS or Android that you have to kind of configure these three pieces of information.
This is kind of the architecture that, if you are going into Appium, or any other tool, for that matter, so if you are looking for an architecture blueprint, this is what you will have. So you will have the CS system, Jenkins is a popular CS system. Then you need to have your solid framework. So the Jenkins one would be interacting with the framework that has a nice layering. It has various components that would simplify your automation work. And you might have a test management system, let’s say Alum or any other test management system that you might have that the framework needs to interact so that it can pick and choose what test cases to run or put the results back into the test management system.
Then the actual Appium tool or the Appium library that would allow you to kind of interact with the device, whether it is a real device or the emulators, you can do that. So the Appium, as I said in the beginning, you will be able to reuse that one script that you’ll return for iWare and Android as long as you use the object identification properly. That kind of allows you to define objects which are common for both Android and iWare. So this is something that you should look at it and make sure that you have a strong framework. So let me take a few minutes to kind of go over the framework, the actual Appium and tool itself.
So Appium comes in two flavors. So one is the UA, so this is what I’m going to show here. So you can see here the Appium tool running already. Like I was talking about, there are settings when it’s specific to Android and iWare. So in Android, you specify what is the and the device configuration, then the actual Android settings. Some of the things are one time settings, but the application setting would be waiting for each version that you are choosing.
One particular piece of information I would want to kind of highlight here is when there is a general setting available, which is common to both Android and iWare, you want to be careful about how you want to kind of pre-launch your application. Whether you want to pre-launch it, or you want to kind of launch it as application is available, then what kind of log information that you want to collect. All of that is available, which are common to both Android and iWare. Let me just close this. Once you start the Appium software, so this is where you will start and stop, there is a nice way that you can interact with the object.
So here, I’m running the contact manager is the sample application that I want to kind of show. You can see that this is actually I’m running on the physical device. The device is available here. And you can see that it is rendering that on the inspector. So you can interact with two ways. You can go through the hierarchy of the application. You can select what component you want to do. Or, if you’re interested, you can just click in different elements that are out there. You can inspect the object. This is the various properties. You want to make sure that, especially if your requirement is to write for both Android and iWare, you want to make sure that you have the right object that you’re using for both Android and iWare.
So some of the things that you can do is this is one that will have object detraction, object identification you can do. But it also allows you to kind of interact with the application. For example, there are various actions that you can perform. So you can select that, and you can say tab, which basically interacts with the application and results and refreshes the screen. And you can see the different objects that are out there. So it is a very nice way to inspect the application and understand the object hierarchy without getting much help from the development team or anybody.
So you can do it all by yourself. There are also some recording features available, so you can click on recording, and it will open up a panel. If you do some high level templates or any action that you do for that will get requirements. So you can also select various languages depending on your trials. And the script will change accordingly. Especially if you want to look for the extract, and you can perform it, and you can get the actual extract. And a little bit of modification we have to do so that you can use it for both iWare and Android. So this is the various features that it allows you to do.
So you can interact with it. I quickly want to show one script that it will return for using this one. This is one of the frameworks that we use for our automation using Appium. So as you can see here, it’s a very simple use case that the user is opening the contact manager and adding the contacts. And this is where whatever framework that you choose needs to be powerful enough to generate, for example, random data into all that. So this is the execution thing. I have a recording, so let me show you quickly so that we don’t – this is an execution video. I’ll just kind of play it.
And as you can see, I’m kicking off the Appium software to begin with. And once I have the Appium software running, it will start my script and perform the operation on the emulator. And the good part is that you can use the same script for emulators, which might be in your local or in the cloud. Or if you want to run it against a physical device, also, it is possible. So that’s the real power of the Appium script that you can use it across the different platforms. So this is a very simple use case to showcase that you can interact with applications.
And as the framework that we use for all of our automation engagement, we use the community automation studio, which has a component for generating the random data. So I’m generating the random data here and creating a contact. So it’s a very, very simple use case. But if there are any questions, we will try to answer at the end. If there are any further questions, we’ll be more than happy to share. I just want to kind of show one more part of it, then I can hand it over to Abhijit to do the demo. As part of the framework that you have built, it’s very detailed reporting functionality that we have, and it gives you a dashboard.
And it allows you to kind of see the screenshot. You can see what all the data, what all the that we have, all that is available as part of the report that we generate. So you can see here, the, and this is for the Appium. And you can see the adding contact that I recorded. It gives you the one data it uses. It also gives you the screenshot that we captured as part of the execution. the stats that got executed. And we also captured the enrollment information. This is very useful if you’re running for, let’s say, multiple devices. We do capture information about which Appium version it was in, what platform, all that will be captured as part of the execution.
And whether it is running for Android or iWare device, all that would be captured as part of the report that we generate. So let me see if I have anything on the next slide. So Abhijit, let me just make you as a presenter so you can do the demo.
Thank you, Siva, for that excellent information in Appium and setting up an Appium test locally. What I’m going to do, folks, is I’m going to take the same application that Siva tested on locally on a local Appium server and do the same test on that application in the Saucelabs cloud. Now during Siva’s demo, you noticed that you would have to set up the Appium server locally, probably have the Android versions that you want to test on downloaded onto your environment. Also, real devices need to be plugged into your hardware.
But Saucelabs really solved that pain point by offering you those removable versions and real devices in the cloud just by making a change to your Appium script where it’s pointing to a local Appium server. You just need to make it point to the Saucelabs server. So we have an Appium server in the cloud. And once your Appium server is pointing to Saucelabs, you’re ready to leverage all the different 500 platforms that you have available to test on. Also, another benefit of running the tests on Saucelabs is that, since Saucelabs owns the entire tech stack, as in we have our own data centers with the machines that we own, we can start our virtual machines from a pristine state.
So if you ran a test initially, and you’re running a second test, the second test will be on a pristine, new, virtual machine. So none of the artifacts from a previous test run will interfere with your current test. And the same with a real device where every test that we run on a real device is from a pristine state. So Siva had a script for that contact manager application in, I believe, Ruby. And I have the same Appium script in Bison. And what we’re going to do is exactly the same thing, add a contact to the application. As you can see on the screen itself, I’m asking that script to be run on a sampling Galaxy S4 device.
And I’m pointing it to run on Saucelabs.com. So let’s go ahead and do that. So I’ve launched my test, and I’m going to go to the Saucelabs home page, or, as we call it, the jobs page. And you can see that, as soon as I kicked off my test from my laptop, it’s now booted up a new Samsung S4 device. And it’s going to iterate to the logic of my test. Another nifty thing about running a test on Saucelabs is you’re able to see the execution of the test real time. So now, my application was loaded onto the real device. And then it’s going to insert a name, a contact, an email, and save it. My test is shorter than Siva’s test.
So you may not see all the steps getting a picture and finish in the next 20 seconds. But we’ll look at a finished test, and I’ll show you how Saucelabs captures videos and screenshots for that particular test. But before I jump into that, I quickly wanted to show you our Saucelabs home page and jobs page. So we ran an automated test using Appium and Sauce, but you can also run a manual test on a mobile web application on the Android version and the iOS version of your choice.
So if you’re testing that component which is the component of your mobile application, with a Saucelabs account, you can quickly launch a manual test from this icon here on the home page itself and have access to all of the different platforms we offer in the cloud. So you see the first two options, the iOS and the Android, and the rest are all the browsers and OS combinations that you may possibly want to test on. We ran the test on a real device, so let’s see how Saucelabs packages all the test results. So here, we have that test that we ran. This was a longer test.
We ran a shorter test earlier. But for each of the interactions that we did with the application, like inserting a contact name, a contact phone, a contact email, Saucelabs takes automatic screenshots of that action for you. So in case you come across a failure during your test that particular step will be highlighted with a red border giving you a quick pointer to where your test failed. Not only that, in case you missed the live execution of the test, and you were kicking your tests off through a build using a continuous integration tool, and you really want to look at the failure themselves, along with the screenshots, we also offer the video of the entire test for you.
So if you’re looking at a failed test, you can click on that video and see all of the steps or the logic that was executed within your test. And we’ll just let the video play for a couple of seconds here so you get the picture and the idea as to how it shows up in Sauce. So you see the flow of your test in the video. The other thing is we also offer you an Appium log. And this is really, again, helpful in a kind of request that the Appium server and the Sauce cloud is receiving and executing. And then we also offer a meta data page within the job or the test itself where you can see useful information about what build was this test a part of, how long it took, and other useful information.
Now, in this meta data page, we also offer the download links for all the screenshots and videos and even the log itself. And you can either choose to download it from the Saucelabs jobs UI page itself, or fetch it programmatically using our rest API. And if you’re using continuous integration to kick off your tests, this simple code to a rest API as part of the post build action itself, you’ll be able to fetch all of the advances onto your local server. And as we mentioned earlier, all of this information about this test is part of a single URL. So I just need to copy this URL and send it to an interested member of my team.
And as long as they have a Saucelabs account, they’ll have access to all of this information here. And just to quickly show you our platforms page here, as I mentioned, we offer close to 500 platforms. You see all of the iOS and Android versions that we offer and the skins that we offer with those versions. And along with that, of course, we have the browser and OS combinations, as well, that you can leverage while testing on Saucelabs. Thank you so much, Siva. And I’ll hand it back over to you.
Thank you. Thanks, Abhijit. Thanks for the data demo on Saucelabs. So to kind of continue on what we kind of talked about in the last 30 or 40 minutes or so, as you are going with any automation tool, I want to make sure that some of the best practices that everyone should adopt, especially when you are doing the mobile automation. So you want to make sure that automation, you are able to at least start with as early as possible along with the CA.
So you want to make sure that, as soon as you have some automation scripts that are running, that the automation scripts are designed and ready for running, you put it into a system like CA that allows you to kind of constantly run that one value data script that – how good or how healthy the application is itself. So you want to make sure that you automate early with the right CA integration band. The second point is right level of automation. So you want to make sure that you are doing automation for the right scenarios, right level of automation, right level of integrations with the different systems that you might have.
You want to make sure that all the differences are being taken care of. The third point I want to highlight is you want to make sure that, strategically, you build your test execution both on emulators and real devices. It’s not that one solution is going to satisfy for your entire need. You want to make sure that a good amount of test execution happens on simulators. And at the same time, you want to make sure that some level of automation is running on the real device also because there are some scenarios that you may or may not be able to catch in the emulator.
Some of the issues only on the real device because of the environment in which the devices are getting used. And the fourth point I talked about in the architecture blueprint also is like you want to make sure that there is a strict layering available. And you want to make sure that the test cases directly do not interact with some of the framework components. You want to make sure that the test cases do interact with the pages, and the pages, in turn, work with the framework components. So you want to make sure that there is a right level of layering and make sure there is a very strict enforcement of the layering of the framework.
And the last point, also, is very important. You saw the level of detailed information that the local execution, the community automation as well as the information that Abhijit shared on the Saucelabs cloud that the data level of information is very important and very critical, especially when there are failures. You want to make sure they’re not able to analyze and identify the failures as quickly as possible because you don’t want to spend – the execution might complete in one hour, but you don’t want to spend four hours in analyzing the failures.
That defeats the whole purpose of automation itself. So you want to make sure that there is enough information available as part of the execution that helps you to narrow down where the failures are. And just to conclude, and the takeaway from today’s session is three things. One is we talked about getting started. So what are the things that you do? What are the key features? There are a lot of features available in Appium Saucelabs. So today, it was more of briefly touching about some of the key features. I would be more than happy to give more information. And we will definitely have continuous sessions like this to share about Appium and other tools.
We did go through and play with Appium on Saucelabs. We did give you a demo on both of the features. But I also strongly recommend whoever is looking to getting into automation, Appium is one of the tools that is very easy to get started. So there is a lot of material available to help you get started, a lot of forum support is available. And just play with the tools, both Appium and Saucelabs. Any tool that you choose, make sure that you go through some kind of a proof of concept because you will see some surprises in terms of what it can do and what it cannot do.
So you want to make sure that you understand what are the limitations, if at all, so that you can have the right strategy for some of the gaps the tool might have. And the last but not least is leverage the industry experts. So this is many of the support is available who can help you in getting the help that you need so that, if you are looking for either a jump start or looking for a training, there are a lot of support systems available for anybody looking into automation to get started. So we, as a strong partnership that we have with Saucelabs, we do provide jump start and on site training on Appium and other related automation tools.
So we’ll be more than happy to talk to you and understand your requirements and come to any help that you might be looking for. So thanks, everyone, for attending this session today. I believe we will open up the questions and try to answer as much as possible today. If not, we’ll be more than happy to take it offline also.
Fantastic. Thank you so much, Siva and Abhijit. That was really great. So we did get a lot of questions coming in. So I’m going to try and kind of bucket them in themes that I saw similar people asking the same thing. Somebody was asking whether or not Saucelabs supports iOS 8.3.
That’s a great question. And I do want to highlight that Saucelabs is very active in adding new versions as they come out. And as we speak, there is active work going on on the back end to support this version.
Great. And then, Siva, this question is for you, maybe for both of you actually. We were asked a couple of questions around this. First, people were curious what types of machines the tests were being run on. And they said if they’re emulators, are they running on VM and what type? And that they discovered some issues that can only be seen on physical devices that don’t occur in an emulator. So they were curious. And then there were some other questions very similar to that about why would I run on emulators and not just real devices? And what were you showing? And I guess your thoughts on that.
Okay. So I can take the part where our emulators are run in the Sauce cloud. And then Siva can address the questions that pertain to his part of the demo. So our emulators, our Android emulators, run on Linux machines. And our iOS emulators run on Mac machines in the cloud.
So to answer to the other part of the question, I think part of the question was why do we run on emulators but not on a real device? I think, like I said, strategically, you want to make sure because the real devices will come with its own cost. Scalability is much more easy with the emulators. And there is going to be cost as going to be one of the factors because, at the end of the day, you want to question yourself and say why am I running if I can do it with, let’s say, half the cost or one-fourth of the cost and just growing. So there is definitely cost is going to be one of the factors.
And real devices also with come with its own – let’s say if you want to switch from version of Nexus to Nexus 5 to Nexus 6. Emulators, it is very easy because you kind of run it on the Nexus 5 or Nexus 6 specific APA’s and other things. So switching from one version to another version is instantaneous. You don’t have to do anything. You can just create the virtual device on the fly. And you will be able to do that. So that’s one of the reasons that you want to make sure that you want to strategically make sure that you are running, at least you cover both emulators and real devices.
Okay. That makes sense. We had a lot of questions just around Appium in general. The first one would be really easy to answer. The question was is Appium a premium model, which is yes. It’s open source. And then another couple of questions. One was how would you write scripts for Appium using Java?
So I can take this question. So basically, there are two ways. One is so if somebody has done Selenium scripting, moving to or starting using Appium is very straightforward because all you have to change is the website and the location of the Appium software where it is running. There are a couple of properties that you have to change. Other than that, practically, you do not have to do anything because you pretty much use the same APA libraries of APA commands to interact with the application text box or the buttons or anything like that.
Like I showed in the demo also, there is a built in feature where you can record the script, so Java is the default option, but you can record the script, and you can take it, and you can modify it. The recorded script is not going to be definitely – is something that you want to run for your production version because you want to take that script and modify it so that it fits into the framework requirements. But yes, so the Java is supported, and it is very easy using the inspector itself or if you want to write it on your own. It’s very similar to the filling in scripting.
All right. So now, there are a lot of questions around automation and doing tests in parallel. So the questions were can I use and achieve parallel execution with Appium? And then another question was can I run tests simultaneously in 10 different iOS devices using Saucelabs or Appium?
Absolutely. That’s another huge feature about Saucelabs is that you’re able to run concurrent tests on Saucelabs on different platforms. So you could have the same test running on emulator or simulator along with a real device at the same time. And the concurrency limit is really determined by you as to your subscription. A lot of our customers run hundreds of tests in parallel in Saucelabs and leverage a cloud to significantly reduce the testing time.
Just to add to that, Saucelabs becomes very powerful when it comes if you want to do parallel execution on multiple configurations because that is one of the limitations and one of the constraints with Appium on local set up because the requirement is that, if you want to run it on cloud devices, you need to have high Appium running. So it’s one of the limitations, I would say, with the current local Appium. And that’s why I think Saucelabs provides the scalability that you might need for your automation.
Great. We have somebody who has a request for you, and I don’t know whether or not this makes sense. But they asked about the framework that you showed in your presentation and in your demo. And if you’d be willing to share that frame work on Github or some sort of sample architecture.
We can understand the request better, and we’ll be able to share if the need be. And we can definitely take that offline, and I can talk to the requester.
Okay. Sounds good. Let’s see here. Is Appium supporting Windows Phone and tablets?
No. So Abhijit may be able to add more, but currently, Appium is only for Android and iOS platform only.
Absolutely. I concur.
Okay. We have a lot of questions that just came in. Another question is just around the emulators and simulators. What are some tests which we cannot run with a simulator or emulator in other ways? What are the tests we cannot perform? They’re just trying to figure out what they can and cannot use emulators and simulators for their testing.
Sure. So I can take this one. Basically, I think this is, once again, kind of common across the different tools of any tools that you might be using. If you go for an emulator, I think some of the situations with, for example, if you have to test interruptions, how the application behaves when you get an interruption like SMS or notifications or phone calls. Those kinds of interruptions are very difficult and are almost when you do it in the emulator. So those scenarios, you have to use the real device so that you will be able to do that.
With the Appium, also, that comes with some other limitations in that all the apps that you are testing, it works for only that app. So if you are to test like the phone app, so that becomes a limitation because you will not be able to kind of interact with two applications. That’s where I think some of the other tools might be coming in handy. But that’s one other limitation that you’re going to be able to interact with two different applications. But back to the question about emulators and real device, so the interruptions are one thing.
And if there are like peripherals that you want to kind of test it with the real devices that icon if you want to kind of see any blue tooth device or how the interaction happens with the blue tooth device and the application, it is better to do with the real device instead of the emulator.
Okay. That makes sense. Okay. We’re running out of time, so I’m going to just do one last question, and we’ll wrap it up. We have someone asking about that they’re already using Selenium and actually Saucelabs as well. So what they’re curious about is if they’re going to be implementing Appium, do you have to just re-tailor your Selenium script test? Or do you need to rewrite them? Specifically, what they’re trying to do is test cases for mobile devices and testing responsive websites.
Right. So a mobile application will have different identifiers. And the way you identify it in Appium is definitely different from how you would do so with Selenium. But if your web application has a mobile web component to it, you can definitely use the same Selenium script to run it on Sauce emulators and simulators as well. And I’ll hand this over to Siva to just maybe give more context around how objects are different within a mobile application as to a web application.
Yeah. That’s exactly. So to answer to the question more specifically, somebody has Selenium already implemented. And they are already using Saucelabs. If they want to use Appium, apart from the Appium installation and configuration, the scripting itself is not going to be any different. You have to use just the Appium driver. And if you are going to do it the real device, you will be doing device ID and some additional parameters that you have to pass. For example, if you want to run against the Saucelabs, you ought to have the Saucelabs credentials and the URL’s.
Apart from that, the scripting itself is pretty much the same. So between the Selenium web application script that you already have experience, so if you want to move to mobile application, you will not see any scripting or much difference. But what Abhijit was mentioning and so that is very important that when you are moving into mobile applications, if you have your framework, or if you are coming with your framework, we’ll support the different platforms. Like the web platform, mobile web, and mobile native. You want to make sure that you are able to leverage that framework for multiple platforms.
So the object is very critical because you want to make sure – so in your framework, you want to make sure that that you are able to identify the objects appropriately based on the platform that you are going to choose. So there are some common parameters of the objects referenced between iOS and Android. Or if you are using Phone based application or CONI based application, the framework itself is abstracting the object information. So there are things that you have to take into consideration.
And that’s where the community automation that we have could allow you to kind of unify the framework across the different technologies that you may want to automate. I’ll be able to give you more information on that if somebody has any questions, you can drop an email, and I’ll be able to share more information on that.
Okay. Thank you so much again, Siva, for your time. I think this was very helpful. And everyone, have a great day.