 And today's agenda is mobile element inspectors. So what kind of inspectors do we have in market now and how it is going to evolve in future? And next is need for speed. How we are going to run our automation scripts much faster than now, we are now. And next is handling multiple simulators at a time, wearables or TVOS support. Inspectors that we develop for wearables and TVOS, how an automation tool is going to support those apps and next is star driven enterprise and it is not mobile first now, it is AI first. So we will go there from how we are now. So have you used any inspectors, can be in mobile or it can be in a web, name any? Anything which we have used? Any inspector tools? Have you giveaways, those who are quite interactive? Yep, anything? Anything for web? We have plenty of add-ons, sorry? Firebug? Yep, pretty cool. Firebug, Firefinder and lot more from Chrome and Firefox add-ons, that is for web. And anything for mobile? Have you used any web inspectors, mobile inspectors? Bit more specific? Yeah, and there are a lot of mobile inspectors currently in market. We have one from Google, which is a UA Automata viewer, which is used to inspect our mobile apps to get the hierarchy and find the IDs or any properties of the mobile elements. And next we have from Facebook, we have one tool called WebDriver Inspector. So group of Facebook techies have developed WebDriver Inspector to inspect iOS apps, especially for iOS 10 and plus. And next, there is another inspector, which is pretty cool. Makaka JS, it's from Alibaba team. So they have developed an inspector to inspect mobile element properties on both Android and iOS, which wasn't before, like Android's UA Automata viewer doesn't inspect elements in a mobile apps of iOS platform and Facebook's WebDriver Inspector for iOS is not possible to inspect mobile elements in Android apps. So Makaka came up with a concept to fulfill these gaps, automate inspect elements in both Android platform and also in iOS platform, that is apps in both the platforms. So, but still there is a limitation, which doesn't render properties for few elements, which is in a UA Automation Platform or UA Automation Library, which is a pretty old library, which aptly deprecated couple of years back. And next is another inspector, which is still in development, that is APM desktop inspector. So it suffices all the needs, like it supports both the platforms, that is apps developed in Android and iOS both, and it has integrated with APM server and pretty cool GUI for now. It's still in a development phase, it suffices all the needs of a mobile inspector, and this is how it looks. We have an app, Odca app, developed internally in ThoughtWorks, so this is how the GUI looks. So we have the properties over here, I think it's not quite clear, it's okay. We have properties, it's similar to how we inspect in our Firebug or Firefinder. So inspect it, get the property and automate it. So that's all about inspector. So if you have any questions, I'll pocket over for last 10 minutes. And next is need for speed, drive faster than before. So how many of you have automated any web applications here? So how fast it is, how fast it is to execute your automation scripts in web application? Yeah, much slow. What kind of inspect, sorry, locator strategy which we have used? XPath. Yeah, any other locator strategies which you have used? CSS. CSS, bit faster than XPath, but not in IE, at least in IE. Any other inspect locators? Similar to web elements, we have mobile elements and with same XPath, CSS path, ID specific to platforms, which is UI Automator ID or UI Automation ID. So XPaths in mobile is much slower than using XPaths in web. So if we identify any properties using XPaths and automate using XPaths, it's bit slower in your, at least in your browsers, Firefox, whichever browser you use. And when it comes to mobile, it's pretty slower. You can go and have a cup of coffee and come back. And still you will see the automation scripts being still running on. So that's slower. So how to make it faster? So when it comes to mobile, many tool doesn't support CSS and even CSS is very slow in mobile. So we have native elements from Android and iOS, UI Automator IDs and UI Automation IDs. We can use that to make it faster. Is there any other strategies that you use to make your automation scripts faster? I have 2000 or 20,000 functional tests. But I need to go live for every five minutes. How is it possible? Any ideas? Have a very big automation suite which has 20,000 automation scripts that needs to be run in just five minutes or in seconds. Yep. We need to run in parallel. Okay. I can run in parallel. Is it possible to complete those 20,000 scripts in five minutes? How much resource do we use it? We need to have plenty of MacBooks or VMs to run everything in parallel. Headless. One more thing with respect to headless. At least you can't run in headless in iOS. It's a limitation from Apple. And still there is not much tools to run your automation scripts in headless mode. And it's not preferred as well. So for example, if you test your mobile apps in Simulator, it is not the same case in testing the same mobile apps in your real iPhone devices. Any other way? Have you heard of Dockers? Yep. So consume Dockers, scale up and scale down the Docker containers in just minutes, complete everything in seconds. Not even five minutes. Simulators is not like there is no support for Simulators or Mac OS. So Dockers have pretty good support only for Android platform. Like we can scale up plenty of emulators, but still it's a limitation from Docker and Apple site. We can't. For Android we can use Dockers, scale up how many emulators that we need. For example, if you are going to run on Nexus 7 or Google Pixel on 13 emulators at a time, scale up 13 emulators in just few seconds. Opening an emulator in Android, it's a little bit painful. It takes at least a minute to open up. But in Dockers, just in seconds. You can scale up. One is ready. Scale up to how many number of emulators that we need. Any other idea to run your automation scripts in less than minutes of time? The scripts. Drop off of the scripts. Half of them. Yep. How do you drop off of the scripts? The risk analysis. Risk analysis? Nice. There are several organizations which goes live every 11.2 seconds. So they go live every 11.2 seconds. Do we do risk analysis for every 11.2 seconds? No, just to decide which test to keep and which to drop. Yeah. But how does that work? Yeah. So these are the ideas. Run your test faster than before using a parallel strategy. Run your test parallel. Speed up your test on iOS platform, especially on iOS platform. To boot up the simulator, iOS simulator, it takes at least 2-3 minutes. Whereas our entire automation suite needs to be run in less than 2 minutes. So speed up the test on iOS platform by improving the locator finder strategies. Use, not to use expert, rather than use iOS predicates or UI automator, those locator strategies. And next up, spin up multiple servers in less than seconds in one node server instance, which is possible in APM. Dockerize the Android environment to scale up and scale down emulator in seconds. And when it comes to APM or any other tools available in market, open source tools, there are some things that APM does which none of the tools in the open source world does. For example, automating your mobile apps in iOS 10 or 10 plus platforms because it's been very impressive and possible in APM. It supports the moment APM released, sorry, iOS released 10 or 10.1, which is not quite possible in other open source tools available in market. The reason, for example, have automated a mobile app, write on automation scripts for that mobile app, functional scripts for those mobile apps in iOS 9 platform or iOS 9 version or iOS 8 version. It's not possible to execute the same in iOS 10. APM under the hood uses a few libraries provided by Apple and Android. For Android, we have UI automator and for iOS, we had UI automation. Those are the libraries which have been provided by Apple and Google. So APM consumes those libraries to automate your mobile apps, functional scripts in your mobile apps. Whereas UI automation library has been deprecated, completely removed from, completely removed by Apple, I think, one and a half years back. And they have introduced another testing library framework called XE UI test. So we have automated our mobile apps. App behaves the same way in iOS 8 or iOS 9 or iOS 10. But under the hood, automation library provided by those platforms like Apple or Android has a more chance to evolve or more chance to get deprecated decision by Apple or Google. So if we have automated our scripts on iOS 9, for iOS 9, it's not possible to execute on iOS 10 because under the hood, library has been deprecated or removed. So we need to think up to another technology how we can automate apps which are built for iOS 10 or iOS 10.1 or 10.1.1 or 1.2. There are open source tools called Calabash or Android, sorry, APM. APM supports both simulators and real devices. It's possible to execute your automation scripts created in iOS 9. Just change your desired capability. Change the capability and run it in iOS 10. Don't need to change anything else. But other tools don't support your functional scripts written on 9 to execute on iOS 10. So that's the limitation that is why we can say like APM does something more than what other tool does. So that's how it is superior. So you can create n number of server sessions, multiple server sessions from single node instance that we create. APM is a node server and a cross-platform tool. Create a functional script and run it on both Android platform, iOS platform. Same script can run on Firefox, Google Chrome, Internet Explorer, Opera. It's the same way. Create a script, functional script and run it on Android platform, iOS platform and Windows platform. It's a Selenium-like script with few or few changes. For example, we used to call click in Firefox or a browser. We used to call click, whereas when it comes to mobile, we have gestures. How many of you have used 3D touch? Cool. Do you find it difficult to use 3D touch initially? How cool it is? We can land in any page like search from the home screen. So these are the new gestures being introduced in latest iOS platforms. How do we automate those gestures? So Facebook provides a tool called Facebook's WebDriver Inspector which has been adopted by APM. Through APM, we can use the same script, automate any gestures. So construct your own gestures, automate it. In Facebook's WebDriver agent, it is possible, whereas in APM, it's still evolving. So any doubts on how to execute your automation scripts faster than before? Do you have any other ideas apart from dockerizing, running in parallel, anything else? Shall we move on to the next? Have two pretty good goodies. Can we be more interactive? I understand it's Sunday early in the morning. So next is handling multiple simulators at a time. Apple has a limitation to open up or Xcode has a limitation to open up only one simulator at a time. So it's not possible to spin up many simulators in iOS platform that is in a Macbook. So how do we execute our scripts in, for example, in 10 simulators at a time? We need to execute our scripts faster than before. So how do we execute it? But still Apple has a limitation. Can we do it? Okay. So like to execute our automation suit in 20,000 virtual machines, like virtual Mac and spin up a simulator on each and every virtual machine. How costly it is? Yeah, it's very expensive. And it's not possible as well. 20,000 simulators at a time if one got broken in between. So infrastructure is very expensive. And so still we need to execute on multiple simulators at a time. Consider we have a 20,000 automation scripts in our functional suit. How can we execute? Any idea? How do we execute in Android first? And so was on the previous slide. Yep, Docker. So any other idea? How can I spin up at least four emulators at a time? So if you have a Mac book or if you have a Jenny motion installed in your Mac book or Windows PCs can create at least 10 to 12 simulators and still execute, but still it's not enough for 20,000 tests. So existing limitation is, as I said, it's not possible to spin up multiple simulators at a time, but still we need to execute our automation suit and many simulators so that we can have a less execution time. So there are few existing solutions. One is a Project Hydra. It's a Python wrapper to run our automation scripts. We have a Python wrapper on top of multiple simulators. So we can execute our automation suits parallely, but still it internally depends on few Facebook tools, XC tool, and it doesn't have much access to the core simulator APIs to override this limitation from Apple. So that's a limitation from Project Hydra. And next we have a Facebook simulator control. Project Hydra depends on another tool called Facebook's XC tool and it's not been actively maintained by our Facebook engineers, but still they have another tool called Facebook Simulator control. Using this tool we can spin up many simulators at a time and run your automation scripts parallely on all the simulators. Next is Blue Pill, another test runner or the test framework which overrides a course which has a very good control on the core simulator APIs. So they crack down and we can spin up many simulators at a time and run our automation suit. Any other ways to execute our stuff parallely, execute your automation scripts parallely? How do you do in Web? And what kind of tool do we use for automating a Web application? Web browser? Selenium? Selenium, anything? Apart from Selenium? U of T? When it comes to U of T, it has very less browser support or at least the latest versions of Firefox or Chrome. So any doubts here? Before going, I'd like to give away a few steps. Thank you. Can you pass it to him? Your good name? Good name? And next is wearables or TVOS support. So initially we use, for example, we have Web applications to purchase any product. So for that we use Web applications of that, for example if we take Amazon, we have used Amazon.com or Amazon.in to purchase any products online. And next comes, we have a support for wearables. So do we get notifications in our wearables? Where is your product exactly here? And then we use to purchase our products while watching our soccer game and TVs. So we have applications for mobile. So we use to buy the same product in our mobile. Then we get notifications in our wearables. Then even we get notifications on TV when we are online or watching something on our TV. So we have applications for this kind of platform. So are we good to write our automation scripts especially for mobile? A separate automation test for our mobile and separate automation test for our wearables accept the functionality made for, like it may have limited functionality, it just notifies where exactly is your product. So do we write separate test for mobile and separate test for wearable and separate test for TVOS apps? How costly it is? It's very difficult to maintain a regression suit which is separate for mobile, separate for Android, separate for iOS, separate for Android wearables, separate for iOS wearables, separate for TVOS apps. But our objective is to order a product in any platform and get notification on any platform. So we need to identify a tool, automation tool that supports everything like coming from a Selenium like script. It's quite famous Selenium like script. Use it on your mobile, check whether the product reaches a particular destination or particular warehouse and check whether you are getting notification for it in your wearables and check the order status in your TV apps but within the same script. Execute on mobile, execute on wearable, execute on TVOS. How cool it will be to execute a same script on all the platforms that we have. So we'll see. So how many of you have wearables here? Cool. What is the most used app in your wearable? FitNubs app? Cool. Yep. And how do you identify that shows the right time? The importance of testing on TVOS but for wearables I think that it's not so important because most of companies are individuals doing wearable application either for fun or be promoted by Apple or Google. Consider you have application on all three platforms like mobile, wearable, TVOS. You need to ensure that where your product exactly is. You don't have a mobile with you or when you are going for jogging in the morning you need to still find where the product exactly is. Do we get it today or tomorrow? And still you have an application in your wearable app and it notifies you where exactly the product is. Do we test it or just go live every 11.2 seconds? Go live in the user's hotel. That's cool. It's cheaper but you have a reputation for your organization. So you spoil the reputation or you give a better customer support. You spoil the reputation for wearables. Okay. So that you will have a good traffic on your mobile apps. Cool but still it's very important and very evolving. At least you have a fitness app in your wearables. Consider you don't have a fitness app in your mobile. That's specific to wearables. You need to be automated before releasing the product. You walk for one hour and you need to identify how much calories you burnt. Is it possible to get that information? And you don't have an app for TV in TVOS. You don't have an app for the same fitness app in your mobile. So consider you walk for two hours and it says you burnt very less calories for the today. So you will walk for another two hours and ensure that. So that spoils the reputation of the organization. So you need to ensure whether everything works properly. Always we can say it's possible to test the app manually. So every time do you test, consider every 11.2 seconds you have a release. Every time do you test manually, 11.2 seconds is over when you just launch the app. So we will see what is the automation tool that supports all these kind of platforms. So we started with mobile. Then it goes to wearables. Then we are having our snacks in our home and get the notifications on the TVOS in watching our soccer game. And next comes we have advanced platforms like we have HoloLens, Google Glass, any other? We are KIT. So we have wearable, wear apps. Sorry, you have? Samsung Tizen stuff. Anything. So there are libraries to automate our wearable apps. Android wearable apps are easy to test using the existing libraries. But for Apple Watch and TVOS are still a concern. It's not possible. Or we can say Apple as they provide XE UI test for automating their iOS apps. They didn't release any frameworks or libraries to automate their wearable apps. But still they test before releasing the product to you and we consume. We consume their watches, apps, everything. So Facebook has a tool called WebDriver Agent again. It's quite popular and works with TVOS and OSX apps. But still not let officially supported, but still possible. And apart from Apple and iOS, there are a lot of cross-platform applications. Or SDKs provided by many companies. For example, we automate or we create an application in React Native. How many of you have heard about React Native? Cool. We have an application in React Native. Is it possible to automate those kind of applications in existing tools? Consider it can be a Calabash or whatever, or APM. The reason is React Native don't expose many IDs or many properties to identify your mobile elements uniquely. Same way, we have a single code base and launch the app in many platforms like Android and iOS. Single code base cloud platform applications written on React Native can be launched in many platforms like Android, iOS, wearables, whatever. So likewise, we have a cross-platform video apps developed using UI Engine. UI Team provides an SDK to develop a cross-platform application. And that is for mainly TVOS, Android TV. They support Amazon TV. It's an Android platform. We can create a cross-platform application for TVOS, Android TVs using UI Engine. So what they did is they created a node wrapper to automate their applications on top of APM APIs. So when they started automating using a Selenium-like script, we'll see how they automate. And it is a single automation script that runs on TVOS devices, mobile phones, iPads, many devices. So we have an Android phone here, iPad and TVOS, Android TV. So it is the same application developed with a single code base developed for these many devices. We need to ensure that application works perfectly on all three devices. So how cool it is? Single code base, execute on Android phones, iOS phones, TVs, wearables. You don't need to maintain a separate code base for different platforms. So they created a new driver called the APM UI driver and they automate their apps, UI apps. Have you heard about Star Driver Enterprise? How many of you are users of Selenium? Cool. And any version in particular? Let us, yeah, that's very easy to answer. Okay, 2.5, 3.0, yep, anything else? So they have a motto to go near to this Star Driver Enterprise, like automate anything and everything using drivers. So what Selenium did is, initially they used to maintain Firefox drivers. And they got the drivers from Chrome, Safari as an extension, Windows driver. And now they convinced the platform owners like, they convinced Firefox team to maintain the Firefox driver. What is the name of the driver now? Selenium's Firefox driver, yep, it's Gecko. So they convinced their platform owners to maintain their drivers. Similarly, APM was not possible to convince their platform owners. And they both run on same APIs, that is W3Spec, which was created by group of engineers from Facebook, Selenium, Salesforce, APM, Source Labs, many organizations. So the spec is being exposed, automate anything and everything using these specs, follow the specs. And without being locking yourself into a particular driver, create many drivers like, in future it will be watch driver, IOT driver, UMP driver, these drivers are like a wrapper on top of these APIs. And APM will still remain as an interface. Direct this to wearables if you are going to automate in watch driver, direct this to mobile if it is an Android driver. So it's simply a node wrapper. So in future we may have web drivers like with the same Selenium like script, execute your automation scripts on watch, IOT devices, or it can be a VR app or UMP driver. And UMP driver is already live, like same Windows script, Selenium like script, automate on any Windows platform. And next is AI first. So recently on a Google Pixel event, Sundar Pichai has told Google is moving from mobile first to AI first. So use the same APM or Selenium like script. But consider if you have a mobile apps that has AI integrated, how do you feed the data to AI? So can be possible if you have a driver for it. It's not possible to automate entire AI, like it's completely different. So a portion of it feeding the data, get the result and still you can't predict the result, but can be asserted from a group of vocabularies or whatever. So same APM like driver, that's where the future is going to. We started with Android, iOS and Windows apps. Then we migrated to VR apps. Then we got TV OS from Android and iOS. Then we have different devices like VR apps and with VR kits, HoloLens from Microsoft, IOT. So we might have a driver over there, which is an extension of APM or Selenium APIs that consumes with driver spec. Then a portion of it. Any doubts? Any doubts? Yeah. I have a question. Yeah. What do you think is the advantage of using Aptim versus Espresso to make an Android application? Okay. Do you have an application only for Android platform? Only on Android platform? Okay. Both Android and iOS. So are you ready to maintain two scripts, develop in Espresso, develop in Elgrey for iOS? Are you ready to maintain the two scripts parallelly? But you have a same app, which because the functionality remains same on both the apps. It's not the same. Okay. The functionality is very different. It's not very different, but there is different ways to complete the same user flow on Android and iOS. Okay. Okay. Consider we have a different applications, a bit different applications on both Android and iOS, but still are we ready to maintain a single regression suit or different regression suit, one and one written on Espresso, another one on consider Swift 2 using Elgrey, which is from Google. Are you ready to maintain? Down the line. Okay. Cool. Then if you're ready to maintain and if you have enough time to release it, it's up. It's your choice. But if you want to maintain a single script and better choice is APM.