 I've been working with BrowserStack for past one and a half year now. And I've been actively involved in making the automate product and the mobile platform for BrowserStack. So if anyone of you have used BrowserStack, you know that we are good enough for at least Selenium testing, right? So today we'll be discussing about mobile devices. Now mobile devices are a bit underrated right now in terms of getting tested. So today we'll be discussing why we need mobile devices. What are the different options available? What should we test? And yeah, and I'll probably give you two demos, right? One on Android, one on iOS, the two famous platforms, right? So yeah, let's begin. So this is the agenda of what we talk, first and foremost. As I said, mobile testing is highly underrated. I mean, the website's getting traffic on mobile is increasing by the day. So we need to understand the need of mobile testing. Secondly, we need to understand what are the alternatives in terms of physical device versus the simulators that are there in the market. What should we prefer and why, right? What are the different tools available? I mean, there are a bunch of tools available. So Google about testing in mobile and you'll get like 40, 50 links. Then an Android setup demo and an iOS setup demo, right? And hopefully we'll get it over in 60 minutes. So yeah, let's start. So need of mobile testing, I'm not sure if you can see that image properly. On the left hand side, you can see the desktop browsers. The permutation and combination of the desktop browsers are fairly limited versus mobile. I mean, there are two popular platforms, Windows or Mac. Linux is basically generally used by developers. They don't make it to the end users. So if you test on these two platforms, you're good enough, right? The number of browsers that are available on desktop are way less as compared to what are the alternatives available in mobile. Mobile right now is in a haywire state. There are traffic coming from small browsers like UC browsers, from South America, India. And then there are native browsers like Chrome, Firefox, for mobile, right? Viewports, that's another thing. Responsiveness, media queries. I guess everyone knows that media queries tend to break when you go from three inches to a five inches, right? Now in terms of mobile, there is phone, there is tablets, and there is also something called Fablets, right? So you need to take care of everything. Then there are interactions, gestures, scroll, swipe, touch, tap. I mean, mobile has got far many gestures. Libraries like PhoneGap, jQuery UI, they just are trying to use that platform, mobile platform for giving out gesture-wise feel inside the browser, right? So that's why we need mobile. I mean, as compared to desktop, you can see there are far more permutation and combinations for mobile, right? Again, next big point, traffic. If you see consistently, there is an increase around 10% every year in terms of mobile traffic. So right now if I see, this is 2013 data from stat, 2014 data from stats counter. And if you see, we are nearly around 27% mobile traffic, right? Now this 27% is, I would say until last two days, till yesterday, right? But we have a huge amount of 2014 still to come, right? So I expect at least 30 plus percentage of data, 30 plus percentage of mobile usage, right? So unless you are a company like Facebook where most of your testing happens on an app, most of your usage happens on an app, you need a website that is compatible with mobile. I mean, personally, I mean, my Indian friends would know, no matter. I won't download an app, I don't need a 2MB app for that. Whenever I need, I'll go to zomato.com and probably search for what food, what restaurant I need to go to, right? So it's highly underrated, the browser testing. Unless you are a big company, no one is going to download your app. So you need to have a mobile compliant website, right? The reason why I'm choosing Android and iOS today, it nearly calls for the 90% of the market. Both takes around 40, 45% of the market. You can see a slight dip in iOS market. Maybe Steve Jobs should have been there. So, and in terms of Android, it's increasing. So that's why I'm probably keeping my talk to iOS and Android for today. But you can see mobile windows, that is also growing, I mean. And once mobile windows grows, there will be IE. So every developer's best browser, I would say. So we need to test there, right? Now, main problem, coming down to where we test. I mean, actual devices versus emulators, emulators. The points that you see are sarcastic. Immulators are very, very unstable, very slow. I mean, you boot an emulator right now, we can have that tea break, come back, and that emulator still would be booting. So we cannot help with that. I mean, if you want fast deliverables, emulators are not the right way to go. And of course, then there is difference of view. I mean, some of our, from our, from Browstack, I experienced a Browstack. We get many complaints around this. My website looks like, A, in a particular format on your emulators or your simulators, and it looks completely different on a real device. What should I go with? How do I debug, right? So we should, I mean, for developers testing few code, few unit test cases on emulator simulators is fine, but no, for production grade, it's not, I would highly not recommend that. I have a small example for that. This is one of our clients, and this is the complaint that he made. So on the left-hand side, you can see how iPhone 5 simulator renders his site, right? And on the right-hand side, I guess iPhone 5 actual device got it wrong this time. So I don't know what, what crap it is rendering. So now it's a nightmare for every developer, right? So real mobile is the way to go, right? So coming to the tools available. Now, we want to test on real mobile, right? So what are the tools available, right? Over Jsonware, Appium, Cylindroid, iOS driver. Now, Cylindroid is again specific to Android. iOS driver is again specific to iOS, right? As the name suggests. I would say Appium provides an abstraction over it. It internally uses the components of Cylindroid and iOS driver itself, but yes, it provides a beautiful abstraction over it, right? So if you want to have an environment for both the stuff, then Appium is the way to go, right? So then, then, then there are frameworks like Calabash. I mean, you write your Cucumber scripts and Calabash makes it work. It's fairly good, right? But it's not Jsonware. I mean, if you have a Cylindium script, you have a Cylindium test cases, I guess I had word with quite a few people in the morning. They have around like 20, 30,000 test cases. I don't think you want to port those test cases to a new framework, leaving Cylindium, right? So Calabash is not the way to go. Record and play, monkey talk. Monkey talk is a very, very good tool, but A, it's not open source. B, on real mobile device, it's flaky unless you have a rooted or a jailbroken device. It works consistently and perfectly fine on a rooted and a jailbroken device, but not that good enough for factor-fated devices, right? So what we will be talking about today, Android will be having a Cylindroid demo and an Appium demo. Cylindroid demo, I plan to skip Appium for testing in Android because it's an extra hop. Ultimately, Appium is using Cylindroid inside, so I would like to avoid that extra hop, personally. Appium, I would be giving a small demo on Chrome, how to run it on Chrome, right? So that's why I need Appium because Chrome driver and Appium and the mobile Chrome are beautifully integrated, right? For iOS, Appium is the way to go. It provides good, good features, good things to probably code sign it. So I'll be running through small scripts also, right? Advantages, open source is the way, open source is the biggest advantage for me. Actively maintained, of course. Cylindrium is actively maintained. And I mean, personally, if I don't find a feature there, I have the code, I can just go there and try implementing that feature, right? So that's the advantages that I see, right? Android, getting started. I guess everyone is fairly familiar with what Android SDK is. So a quick run through, Android SDK, developers.google.com, go there, download Android SDK. It gives you some binaries like ADB, DDMS, and those sort of binaries, right? They will be useful. They, when you connect your device to your machine, that's the bridge that your machine will communicate to the device through, right? Few commands, ADB devices, list down the devices, right? Maybe a small, I can help you with that. I guess. So right now, I have got this Nexus 5 connected to it, right? So maybe, sorry. Oh, yes, yes, yes. I'll be going through that. I am not sure why my resolution is good. So this is the Nexus 5 that I'm running right now, right? And if you've seen ADB devices, just shows the serial ID and the device name, right? And a quick look at ADB lock cat. Every developer should use this, tailing the system logs, what's happening in my device, right? It just goes on if anything happens, right? So that's the two commands. There are many commands. I mean, there is ADB shell, there is to start an app, stop an app, but all those abstractions are already there in whatever tool that I'll be explaining. So you don't need to know those commands, but yes, of course, we can probably discuss offline if someone is interested. Before we start, enable USB debugging. Okay, on every device that we do, we need to enable some developer options. The device are not meant for developers, right? So we need to do, for Android, you have to enable USB debugging and you have to allow applications from unknown sources if you don't want to end up in a mess. USB debugging allows you to communicate right now. This device is already enabled. So I'll show you a quick option of how to do that. It's in, so if you get a factory fitted device, if it is Android 2, 4.2 plus, you will need to tap this build number multiple times. As you can see right now, it says that I'm already a developer to enable the developer options. Once you have done that, you go to developer options, you click on USB debugging, which is enabled right now, right? So that's all you need to do. Once you enable this, plug in the device, and for this demo, I had to already do this because I could not screencast it without enabling USB debugging. So that's the only tick mark that you need to check before you start, right? So that's it. Of course, I have also allowed it from unknown sources, again, the settings, right? They differ from device to device. Android 2.3 has got different set of device, but Googling it would be fairly good enough, I mean. It's just going to applications and development and USB debugging in Android 3 and below. So that's it. Okay, now coming to Solendroid. Now, how many of you are familiar with what WebView is? Okay, so that's quite few. WebView basically is, I would say, inside a native app, you can embed a browser, right? Now, that's an actual browser. You can load a page, you can run JS tests, you can check how the JS will behave. That's a browser inside your native app, right? Now, WebView is very, very famous and that's an API provided in both Android and iOS, right? Now, the problem with Android, particular problem with Android is, if you see, there are many, many providers, unlike iOS, where only Apple manufacturers are iOS, Android has been given by different OEM providers, right? So the browser that is packed with Samsung is completely different. Browser that LG gives is completely different, though they are more or less variants of WebKit browsers, but it's very difficult to automate every Android device that is out there in the market. But there is a common WebView API that Android provides, which is around 90% to 95% accurate to the real browser. I have not personally faced any client, or personally I have not faced any site where it differs on the real browser and it is very, very different on the WebView, right? So WebView for Android is more or less stable. So I'm choosing WebView in Cell Android because, again, I cannot automate all the browsers, and Chrome is being packed only after Android 4.3 Plus, right? So let's start with a small demo of running it. Let's say we do this with an Android 2.3 device. Okay, so the internet is flaky, so pardon if Google.com doesn't open here. Yeah, so I guess that's the S2, right? Coming to the code. So Cylindroid requires Cylindroid.jar. Now, again, you can go to Cylindroid.io and download the jar, or you can just clone Cylindroid and Maven package. It's as good as that, right? So once the Cylindroid.jar is running, it is as good as the standalone jar that we use for desktop application, desktop testing, right? You just do a Java minus jar and Cylindroid, sorry, Cylindium server.jar, and that's as good as doing that. So I have a small SH file. I am not sure if, is the font visible? So yeah, so just before you start, you just need to export an Android home. Right now I've got that in my ZSS RC, so I don't need to do that, but Android home is basically part to that SDK. So if I, so right now it's in my users tools Android SDK, right? Now inside that, just remember you give part to Android SDK and not to platform tools, where ADB is. It requires part to Android SDK and not platform tools, right? So and then that's it. You just need to run that jar and I'm running it on port double five, double five, right? So let's just go ahead and run it. So it says that the server has been started at double five, double five, right? Now to confirm, like WD, there is something called as WD hub status, which is from the desktop browsers, right? Again, I'm not sure how much can you see that, but shows that currently I have a GTI 9001, which I 9100, which is the model number for S2, right? And it gives me different things. The API level is 10 of that device. That is a platform version, screen size, and it's not an emulator, of course. If it is, then I don't need to stand here. Okay, so again, now let's run some code on it. Yeah, this is so cool. Yes, so if you're testing a raw web view, you don't need to do that. I mean, if you are testing an app, if I don't specify anything, it assumes that you are going to test the web view. That is, Yes, yes, yes, of course, of course, there. Okay, okay, I guess the app, how are you passing the app ID? That depends on that. I mean, before class. Okay, that's in the code, right? But yes, yes. So before that, while you start, when you start Selendroid, in here, you need to specify app, APK, okay? So I would like to, I'll be happy to help you, but the problem is I need to understand your test case, because unless you specify minus app and the app ID and then while running your test, in capabilities, you need to pass app, which app you want to test. So maybe we can take it offline and you can come to Browstack Booth and I'll help you with it, surely, right? But for now, I'm not concentrating on native apps. I'm more interested in browser testing, right? But I'll surely help you with this, right? So, yeah, Selendroid. Small Google.com test, I hope Google.com opens in that Flake Internet, right? Go to Google, get an element by name queue, okay? Ruby, anyone issues with reading Ruby? Anyway, so self-explanatory code then, right? So let's go ahead and run this. So you can see the web view opened, right? And I'm hoping that Google.com will open soon. Yes, awesome, right? So that's the code. That's how it's easy to integrate a 2.3 device. This is like fairly two years old now, more than two years rather. And you don't need to do anything. The even closing the app, clearing the app is taken care of by Selendroid. You don't need to do anything. So this phone is now as pristine as before. I mean, before starting the test, right now it's as good as same. There is no data, there is nothing there, right? So you don't need to worry about any data, any security that is being held here, right? Of course, there are a few apps we'll be getting installed here. So Selendroid uses instrumentation to do that, right? So Selendroid supports native hybrid testing too, as Sir said. So we are concentrating on web app only right now, right? Automating browsers for now, right? It supports gesture, though the vanilla Selenium package, like in Ruby Selenium web driver, vanilla Selenium web driver won't have those gestures command, but Selendroid has got its own bundle too. So you can download that bundle and you can even explore the gestures API, right? Yes, awesome WebU inspector, a small demo on that. I'll have to comment few code. Let's say I don't quit this browser. Google.com is not working, let's see if inspector works. Yes, of course, so I'll be sitting in Browstack booth. Also, I'll be making sure that this setup, if internet supports me, I'll make sure that that setup is running there smoothly, right, so that you can actually probably look around. Yes, yes, yes, of course, of course. So this is a WebU inspector right now, I don't, internet is not working, so you can, like we have inspectors in Chrome, you can just inspect elements and try to find out what element does what and you can write code accordingly. So this is a very, very cool feature. The session has to be running during this time, so that's why I commented out driver.quit, but this makes life much more easier. I mean writing test codes is, for me, is like going to Chrome inspector, finding out how to probably name that element, by ID, by name, by class name, so this helps you out with that. This even helps you out with the native apps, to some extent, not entirely, but yes, to some extent. So you can, this is a very cool, so you can just go to your port slash inspector and it just gets appended automatically. The session ID, the current session ID, right? So yeah, that's about it, about Selendroid, right? So just to save and hop, I had Selendroid testing, right? Coming to Appium, Appium. Now, I would not prefer Appium for WebView testing. I mean, if I have WebView, then again, I said save and hop and just run Selendroid. You don't need Appium for that. But if you're using Chrome, I mean Chrome 33 plus, it's not bundled by default with any of the browsers, right, so the current, even if you get a new Nexus 5 right now, it comes bundled with Chrome 32. You can, of course, upgrade it to the current 35, right? But any phone and any Android phone, having Chrome 33 plus, you can run this Chrome testing in it, right? So by Chrome testing, the main advantage is your desktop test, I mean, the one that you run in your desktop Chrome, they just get ported to your mobile Chrome, right? So you don't need to do anything special. Now, in the below versions of Chrome, this is supported via Chrome driver, but you need rooting. I mean, it's not supported on Christine device. You need slash data access. So I would not prefer rooting. Though on my personal phone, I would prefer rooting, but for testing, rooting is a no, no, strict no, no, right? So let's kill the Selendroid app and we have moved back to Nexus 5. It has a Chrome, right? The latest Chrome, you can see, right? So I'll close this. So for running Appium, again, not sure if, anyways. So for running Appium, you again need Android Home, as always, and Android Home is basically Android SDK, to the Android SDK. So any application, even Calabash, even MonkeyTalk, everyone requires Android Home, right? So in this, if you see, I have given an extra param, browse the name, which is Chrome. If you're doing app testing, then it's minus, minus app, and then name of the app. And again, I'm booting on double five, double five, right? Also, the code that I'll be running, let's run through that too. So again, hello world in Google, right? With default, with Android preset and getting the driver from localhost, double five, double five, right? Let's get started with that. So one good thing about Appium is it boots very quickly. If you have observed, or it took some time before it said that the port is on double five, double five. Appium boots fairly quickly in that matter, right? Because it's no GIS again, versus it's old Java. So yeah, we have the Appium running on double five, double five. I do Ruby. This resolution is going to kill me. And my test failed. Now one particular tricky thing about Appium is, it requires this extra capabilities. In case of Cylindroid, I used the default preset. I did not have to pass any extra capabilities, right? But in case of Appium, you can see it requires device name and platform and capability, right? So that's why I just commented out that code previously before when I was on this page. So platform name. Now in traditional Cylindrium, the, it's, this platform name has got surname as platform, right? And it takes Windows, and in Windows it takes Win, Win8, Win XP, those are the subcategories, and then either Mac, and that's it, Linux, right? But in case of Appium, it takes Android, iOS, and Firefox OS, right? So I need to pass platform, and it's not platform, it's platform name. I don't know why they did that, but, so it's colon Android, browser Chrome, and device Android. In case, so device capable, device name, in case of emulator, you just have to do this. Android emulator, and it should probably run on Android emulator, right? So let's, let's go ahead and comment this and done it. And where's the demo? So the data colon that you see is from the desktop Chrome. Even desktop Chrome boots up with data colon. That's it, the test, I mean, it's that fast as compared to Cylindroid, where it took some time, I mean, booting up that app took some time. So it's not only with 2.3, even if I run that Cylindroid setup on my Nexus 5, it will take some time because it has to install a foreign app as compared to just booting, just starting a Chrome that is a default browser in the recent Android, right? So that's pretty much it about Android. Again, any questions, I would highly appreciate we can take it offline, right? Because I'm not sure if I have time. Coming on to iOS, right? As I mentioned, iOS is not developer friendly. At least not tester friendly. Unless you want, you want to automate something, it's not that friendly. So what you need, like Android SDK, you need Xcode and command line tools, right? Installed, current version around Xcode 5 plus. I'm using 5.2 on my machine, right? You need a developer's account. To test on real device, you need a developer's account with Apple, which is a paid service. I mean, it's not like Android developer's account, right? So you need developers account for two things. One is the provision profile that you need to install on your phone, right? Saying that ABC has access to this phone, right? And that ABC has to sign all the apps using the code signing certificate that Android provides. So these two things are must, right, for Android setup. Sorry, iOS setup, my mistake. Cool, so before we start, in iOS, let's open reflector. Yeah, there it is. So I'm using AirPlay and let's go to settings. I hope the screen is visible properly. So like we enabled USB debugging for Android, you just need to go to Safari, Advanced, and you need to enable web inspector. Now, why you need to enable this? Because you will be communicating via JS. So unlike Android, where you are using the native things. I mean, for Chrome, it's the Chrome driver, right? Which communicates directly with Chrome. iOS on real mobile device is not native. It's JS injection, like we had in Selenium RC, right? So you just need to do that and you need to install the provision profile. So right now, I have got that turned on already. And again, I have installed the provision profiles also. So my machine is more or less set up for this, right? Quick run through this, like we had ADB, right? For iOS, there is something called as Lib iMobile device, right? Now you can just download it via any popular package manager, right? Brew, port, everything supports that. So you can just download, you can just install that. And there are few binaries that it gives, like iDeviceID-L, that you see here. I'll just probably highlight this thing. This guy will tell me how many iPhones have I connected, like ADB devices was there, right? So let's go ahead and do this. So I have one iPhone connected, iPad connected, sorry. So it doesn't give me much more information about it. And then there are different commands like iDeviceProvision and similar commands. So you can just go ahead and explore those commands. iDeviceProvision, a quick run through, again, it is useful for managing the provision profile. I mean, you can install the provision profile, you can remove the provision profile, you can get the list of provision profiles that are related to the iOS device right now, right? So this is, I have already run the script and I have got this mobile provision certificate already installed. This is a binary that you can download it from developers.apple.com, right? It's actually not a binary, it's just the list of, it's just encrypted data of list of devices registered under your ID. So this is the iOS setup again. So I'm using something called as iWebKit debug proxy. This is provided by Google, right? This uses the web inspector that we turned on. We need to communicate to that web inspector via that proxy, right? So this is like any other WebKit debugging. I mean Chrome provides WebKit debugging, Chrome provides mobile debugging, right? So you just go to Chrome, you connect your, you open your Google Chrome and you can debug it on your desktop browser, right? So that's why we need this iWebKit debug proxy. Now, Appium is part of the port. So make sure that this debug proxy always runs on 27753, right? And that's where Appium will search for that proxy and Safari communication, right? And in this case, we are passing extra parameters, dollar device, which I'll be passing as an argument. Now the device is the same one from iDevice ID minus L, right? What I want to automate in this case, Safari, right? Port, again, not mandatory and these are some optional parameters, logging and things like that, right? So let's go ahead and just run this. Need to kill this first. Okay, so it said that I had to pass the device ID. And yeah, I have two devices. I'm using this for tethering. So this is, this ID is for my iPad, right? So again, server is booted on double five, double five and example, again, platform name, device name, mandatory, app Safari optional, device name, again, it just becomes iPad simulator, right? In case of, if you want to run on simulators, also you need to do some different configuration for simulators. To authorize simulators. Those all scripts are available in Appium. That's why I would prefer to go with Appium for iOS. The scripts automate many things for you, right? So, pardon me, I don't have internet, so I'll not be automating Google.com here. I'll be automating the local Wi-Fi that is there. So I'm sorry for that, but let's start. So you must have noticed one strange thing. There was something called a Safari launcher in between, right? Unlike Android, you cannot launch any app in iOS unless you have something inside iOS, right? So what Appium guys thought is they just build an app that request for an URL, right? So it just says, from an app, it just says that I want to open apple.com, right? Now when you open apple.com, it just opens in Safari. And once Safari is open, the debug proxy is on. So it, by default, routes all the debug, the JS or the debug proxies to it. So that's why we need a special Safari launcher app, and you need to sign that Safari launcher app with your code signing certificate. You need to sign that Safari launcher app with, and I've got an equivalent code signing certificate through which I have signed my Safari launcher so that it runs on this device, right? So that's probably it, I don't, I could not make Google.com work on it, so I just automated that thing and cannot help with this, right? Let's, so coming to the future, I mean, again, all the questions, we can take it offline. If time permits, we can take it right now also, but I'm not sure if I have time. So we can, we can surely take it offline. So coming to the future of mobile, as I said, Windows is growing very aggressively. At least this year, Windows has seen a very, very substantial growth, right? So, and again, as I said, it brings I, so developers will have some surprises. So we need, that's what, that's what Browstack or that's what we feel that needs to be automated. Next, upcoming browsers, right? Like Chrome is automated, I mean, I would love to have all the browsers automated. Mobile Safari, mobile Firefox, mobile Opera, UC browser, I'm not sure how many browsers are there, but at least the famous ones. I mean, Firefox should be automated, right? Again, when I talk about Chrome, it's only automated for Android, not for iOS devices. iOS have Chrome installed. You can install Chrome in iOS, but again, Google says that it works completely different on iOS and it works completely different on Android, right? The second thing is native versus JavaScript. Probably if you come down to the booth, I'll show you one example wherein yahoo.com, yahoo.com is one of our clients and they are not able to use our iOS setup because they need to play a video, right? Now that video cannot, when I do and find element x, y, and I say that click that element, right? The video doesn't play because what Appium or what Automation Injects is JS and that is not supported by that format. So we need native testing, right? So the problem is in iOS without jailbreaking the device, it's fairly, fairly a complicated task. But yes, we will reach at that phase and we will hope that Apple becomes a developer friendly company someday. So the demo, it looks good. I mean, you just connect the device and yeah, you are up, right? But it's not, trust me. When it comes to scaling the product, it's very, very difficult. Firstly, real mobile devices, no virtualization. I mean, you need to have that hardware with you, right? So it's expensive. When I talk about platforms, I mean Android 2.3, 4.4 and we are looking at the new Android L, right? iOS, we are looking from iOS 5 to the iOS 8, which is expected on 9th, right? Then there is Windows, then there is BlackBerry, I mean multiple platforms, right? Then there are fragmentation in that platform. I mean Android, and Android 4.4 behaves completely different on Samsung platform and it's completely vanilla on a Nexus device. So that too is critical, right, for testing. Then there is update management. How many browsers will you update? How will you update? What browser needs to be updated, right? So it's a pain. It's a nightmare, I would say. And making multiple devices work again. That's the biggest challenge that I have faced personally, building a mobile platform. I mean, it's not as easy as connecting five devices and yeah, you are up and running, by running some small Selenium jar or maybe anything, a small script. It's not that easy. It takes time, right? So, BrowserStack, you can probably sign up with BrowserStack and we volunteer as a tribute for you. And we have an iOS setup running, so maybe you can sign up with BrowserStack and run some scripts on iOS, right? And those who are very keenly interested, we have a very, very close beta for Android, right? Probably, probably, I can give you a small demo on how we are looking out with Android testing, right? So, cool, that's it. I'm not sure if all of you have seen the video, but this is what we something, something I take pride in, I mean. This was our first DC setup, right? And this has become a trend, like this is how we need a nine-gag at BrowserStack now. So, yeah, that's it from my side. I mean, if you have any questions, surely you can ask right now or maybe we can take it offline. So, these are the five set of iOS devices on the right and Android devices on the left. It works very smoothly across all the devices, just that making the entire setup work with multiple devices is a tricky task. Yes, basically, so Appium internally uses Seleneroid for, if I'm talking strictly about web views, right? When we are automating web views, it internally uses Seleneroid. So, it's fairly the same architecture, so it's the same. Yes, that's the Seleneroid inspector. So, the demo that I showed, that was with Appium and Chrome. Now, Chrome has got a default inspector. With a Chrome browser, you don't need anything. You just can plug in your device, open Chrome, and on desktop, you can open Chrome and you can inspect all the web pages on Chrome. Yeah, yeah. So, inspecting Chrome is already there. I mean, it's not a new thing. Not right now, not as of now. They are all connected to data center backbone. But, yes, going forward, there will be variants, but right now we are concentrating on functional testing mode. Yes, so, we have a dashboard for this. I'm not sure if internet helps me here. Yes, you can come to our booth. It's video recorded, but let me just try. No, so, we want to build that, but the problem is, okay, let's say you have 1000 calls, 1000 Selenium calls that you have made in one test, right? Or let's say, not even 1000, you have 100 Selenium calls that you have made in one test. Now, the problem is, let's say you do, in one second you fire a JS event and you do a send keys, right? Now, how will you figure out in a video that at this exact moment I did JS and that broke my test versus the send keys broke my test? Maybe send keys is figuring out some Java, right? So, what do we do is, yes, so, what do we do is, we have an alternative for that, debug screen shot. So, by debug screen shot, we take full desktop screen shots at all the calls that potentially can change the DOM structure. You inject the JS, you will get a debug screen shot, you do a send key, you will get a different debug screen shot. So, you know that, okay, when I did inject JS, the page looked like something like this and when I did send keys, the page looked something like this. It's easier to identify. As a developer, I would say it's easier to relate as compared to what you see in the video. Yes, debug screen shots are, again, I'm thrown out of this, but debug screen shots are available. Yeah, so debug screen shots are available on the automated dashboard. They are always there. You can refer to them. Okay, that's a very, very tricky question because that again depends on what kind of site you are testing. How are you testing? Again, that's a completely, your test case specific scenario, right? So, but in terms of reproducing it, let's say right now if you're testing on desktop browser on i6 with browser stack, right? There are high chances that something will break. Some CSS will break. So, what you do is, you have an equivalent i6 on your local setup or you go to browser stack live and probably try to debug what went wrong, right? In terms of CSS. So, we are trying to build a similar kind of platform like we have for desktop wherein, let's say you run an automatic test case and if something breaks, you click a button, you go to the real device with that site and you can try to debug around what's going on. So, that part is still left. Right now, we are just there with automate, but surely we'll help debug live too. Yes, that's what, so that's what I explained, right? Yes, there are, again, then there are problems with the updates. As I mentioned, I mean, the updates that are there for Samsung devices comes from different domain and they update in a different fashion. Though it's not completely different fashion, but there are some scripts that are different from an LG phone, right? So, update is the main thing. Updating the browser, updating the web view, updating the API, updating the OS itself, right? And that's true with even iOS. I mean, on ninth, you are looking at iOS 8 and going by what they did last year, breaking all the instrumentation calls from iOS 6 to iOS 7, I'm not that positive. So, all your script starts breaking when you update the OS. So, those are the challenges that we see in terms of platform. Yes, of course. Yes, that's why we volunteer as a tribute. Again, a client-specific question, a client-specific thing. I mean, if you're testing Google.com, it'll work, but let's say if you're testing something like nangag.com, it won't work, because nangag renders a full desktop version on an iPad, but it renders a mobile version on an Android mobile or an iPhone 5 for that matter, right? So, that depends on what kind of CSS or what kind of engine that you are using in behind, if it is a responsive site, and if it hides some element, if it shows some element, then again, it becomes client-specific. But mostly, if you're using frameworks like media queries, which has been arranged recently, you should be fairly covered. Statistics, what kind of numbers? Yes, of course. So, every selenium call, we mark every selenium call with the amount of time it took. So, you made a selenium call on X seconds, and you got a reply, we responded back to you in X plus two. So, we'll show that, let's say, that call was send keys. Send keys took two seconds. So, that, all those calls will have appropriate timestamp. You can also measure, in case of, if you're debugging performance from your end, you can also measure that last response that Browstack made was at X second, and the next request that I made was at X plus two. So, there is a two-second latency. There should not be a two-second latency, but yes. I guess this side slept. I don't have that internet working, let me just, Airtel is not working for all my devices. If you can come to the booth, I would probably help you in a better way. It's not working with any of my devices. Maybe I'm the chosen one. Yeah, it's working for everyone. I mean, even for my colleagues, it's working. It's not working for any of my device. So, let me just try. Said awesome too early. So again, the resolution is bad, but, so this is how the dashboard will actually look. I can, do you able to see the font? So, this is how the browser took, let's say starting browser took, so this is an internal Browstack dashboard. So, expect all kind of rubbish data here. So, starting browser took 10 seconds. The duration that you see here, answering the question. Duration that you see here is 10 seconds. URL opening took 12 seconds. Get title was immediate. If you want something in milliseconds, you provide your logs. So, in here you have all the, so in, and all this is available via API, so you don't need to worry about automating this stuff. Anything else? Yeah, yes. So, as I mentioned during the start of my talk, unless you are a very, very big company or a very, very famous app, your website on mobile will be measured more. I mean, that will be used more, right? As I gave an example of Zomato, I mean, nobody downloaded Zomato, right? So, people tend to go to Zomato, Zomato.com from a browser, search what they need and just forget about it, right? So, yes, we are targeting native apps, but not as of now. Our first motive is to, as the name says, Browstack, first motive is to support browsers, which is fairly a big, big market. It's not about a problem right now. Okay, so, I would say, let's say, if I give you an option between testing a native apps versus giving you an option to interact with an iPhone 5, you will obviously prefer interacting with iPhone 5, right? So, I mean, for debugging purpose, the first thing that you need is to, like you debug your handle device and you debug issues on this handle device, you want to have debugging like that, right? So, live is the main thing. I mean, live is what we would target. And creating a platform for a browser gives us a strong infra, right? Right now, as I said, Android is in a pre-beter state, right? Where there are slight flakiness with Android, right? So, once we solve that, then of course, it won't take time for native testing, but we want to make our infra more stable and we want to have customer interact with the devices first, right? That's an obvious reason. I mean, I personally would, I mean, if my test crashed, I would like to know where it crashed, how it crashed, want to debug stuff. Yes, exactly, how will you debug stuff? I mean, you need to interact, right? Like the gentleman said that, how do I reproduce issues? Let's say you are not able to do a swipe, right? If you do a scroll, a scroll and a swipe are two different things, right? So, if that changes your site's behavior, then that's what you will love to know first, that was a scroll or a swipe.