 היי, everyone, welcome to Ferranium India. I'm excited to be here and my session today is going to be actually related to the previous session talking about innovation, what's new, what's coming in web, in web development, in web technology. I'm going to address progressive web application testing strategies, and this is what is happening these days in the market. There is a serious transformation by major enterprises, and I will show you some demos that are switching from traditional web applications, websites, mobile websites, responsive websites towards progressive web applications, and there are reasons why they are doing so, and I will cover the reasons, and I will cover at least my agenda on if I am in your seats, I will build a test plan for progressive web applications. Just a brief, what about myself? My name is Eran Kinsbuner. I'm a director and evangelist at Perfector. Perfector is a cloud company providing infrastructure for testing web and mobile native applications in the cloud in different locations. I'm there for the last model six years actually. Before that I worked at Sun Microsystems on the Java to micro edition SDK. I'm the author of the digital quality handbook and working on the second book that is about to launch later this year. I'm actually sharing and collaborating with a few guys that are in the room right now on the second book, so stay tuned. In today's session I'm going to talk about the DevOps transformation and what leads towards the adoption of progressive web application. I'm going to talk about what is a progressive web. Not many people are looking into this technology and are not really familiar with what is progressive web, so I'll try to guide you on Army with what it takes to actually move from one web application to a progressive advanced application. And if there are time for questions after the test strategy definition, I will be happy to take questions. I'm here all day, so if you don't catch me during the session, you can catch me after the session. Just one word about the image, what you're seeing. This is the Guardian website in the UK. It's built as a progressive web application and as a teaser, progressive supports offline caching, meaning if you have zero network connectivity by the implementation of progressive web application, you can actually still get content and engage with the website. And when the Guardian is offline, the attendees or the users of this website can actually do some puzzle and crossroads, so that's one way of engaging with the user even when you have either zero network or slow network connectivity and it's part of the implementation. So pass versus the future, how many here are doing web testing on a responsive web application today? Almost everyone. It's not the past, it's the future actually, but it's the current. The future of responsive is progressive. So progressive web, if you want to think about what's really the future, it's a responsive plus one. It's an advanced responsive website, web application, which has much more capabilities that are bringing the web closer to a mobile native application, user experience and capability, and I will tell you and show you how it looks like. Today, there is a huge gap, but it's closing between mobile native applications and web applications. It starts with sensors that the mobile devices have and the web doesn't or has limitations in engaging with sensors. It comes to different network conditions that the mobile devices work with, 3G, 4G, these kind of things, different carriers compared to the website, and there are many others. There are sensors like Face ID and fingerprint that you have on the mobile and you don't have right now on the web. This bridge or this gap is getting closed by the browser vendors. We see both Chrome as the early adopters as well as Firefox and Microsoft Edge Safari from iOS 11.3 also supports progressive. So most of the browsers are starting to close the gaps in bringing the mobile capabilities into the desktop web. We see today, if you go to Google.com, which is a progressive web, you see the icon of the microphone. You can actually inject voice to Google from your desktop, not from your mobile. You can do the same thing with locations and some push notifications today with different desktop browsers. You get this allow and block all the time in your desktop browser. So there are already capabilities today in the desktop web that are close to mobile but it's still not complete and the browser vendors from both Microsoft, again Mozilla and Apple are starting to close these gaps with moving towards progressive. I don't know how much you can see back there, but that's a nice website. I don't think that everything that it's in here is fully accurate, but it's kind of showing you the differences between different browsers and how they support different capabilities. So if you look at the left hand, this is the Chrome on this Windows 10 machine, on this Windows 10 Surface. On the right hand, it's an Edge, Microsoft Edge 17 on the exact same machine. You can see that there are some red marks here which are green here. I can read it for you guys. So home screen installation is not supported on the Edge 17, but it is supported on the Chrome on this Windows machine and I'm not even taking it to the mobile devices. So even on desktop machines, the browsers today without responsive and progressive technologies vary between the different capabilities and from a testing perspective you need to be aware of these capabilities. There is a website called What My Web Can Support Today. I have the URL in this presentation. You will get it. You can just go to a website and see what is supported from an API standpoint and how you can engage with the web from your application as well. So let's dive into mobile native versus progressive web. Today when you're developing a native mobile application, you need experienced teams. For iOS, you need guys who are strong at Swift, Swift code development. With Android, you need Java developers and for web, you need Java and JavaScript skillset within your team. So these are varying skillset and also varying technologies. We know that for native mobile application in the keynote, Appium is the de-factor, Selenium is the de-factor for web, but you also have Xeritest and you have Espresso. You have different frameworks, different skillsets, different technologies that support different native mobile applications. And oh, by the way, once you develop the native application, you need to also deploy it into the App Store, right, to Google Play and to the Apple App Store. And it's a process and if you're thinking about DevOps, agile, continuous deployment, going all the way through the App Store after fixing a bug and, you know, waiting for the approvers and all this process sometimes takes time and you want to be much more agile. Progressive, in a sense, comes to kind of bypass the App Store with permissions, of course, from Google and Apple. It's not something that is a hack. Apple and Google are supporting Progressive as part of their browsers, but it's something that doesn't go through the App Store and has only one source code from a skillset perspective, both from testing and development. So that's a huge advantage for developing Progressive Web compared to a native app. Still, there is maturity and I will talk about the differences, but from a mindset and from a thinking forward, organizations like eBay, Pinterest, Twitter, Instagram are already implementing today. It's in the market today, if you go today to instagram.com or to pinterest.com, flipboard.com, you name it, you know, and you add a shortcut from your smartphone, Android or iOS 11.3 and above to your smartphone home screen, you get a Progressive Web installed on your app without going through the App Store. You have kind of a native app running on your smartphone devices without installation through App Store, you know, all this certification that you need to go, UDID, you know the mess with signing application and these kind of things. So let's be a bit more educated about what is a Progressive Web. So basically, if you go to Wikipedia, it will say a lot of words, I will summarize it for you. Progressive kind of brings web and mobile together, okay? It bridges the responsiveness of the web application, what you know from Responsive Web and most of you are doing Responsive Web today. So Responsive Web means you have consistent user experience across all different platforms, mobile and web. Progressive on top of that brings also advanced capabilities. I will name a few, offline caching, push notifications, working with sensors, camera, location, audio, the microphone of the device. So if you want to inject, like work with serial, inject a voice, record a memo from a Progressive Web application, it is supported today. Doesn't work well on iOS, works better on Android for my research, for my initial research, but Apple is catching up with Progressive Web capabilities as part of Safari, okay? But still, these are, in a nutshell, this is what a Progressive Web application means, okay? Responsive plus advanced capabilities. This is a long list of benefits that Progressive Web application actually guarantees or promises the developers of such applications. And I mentioned the offline caching, right? You can work with almost zero network or with no network at all. Due to this offline caching, you can register your Progressive Web application to get push notifications. Imagine twitter.com today, everyone is tweeting from Selenium conference. Twitter is a Progressive Web application today. If you install Progressive on your iOS device today, you will get Twitter Lite, that's the name, okay? And it can register to get push notifications when someone is tweeting, like any native Twitter mobile application that you are familiar with. It's responsive, I told you, it's a superset of responsive Progressive, so it works on all the devices. I found some bugs, I will share with you some of the bugs, but it's supposed to be a responsive kind of application. If you look at what the organizations that already are early adopters of Progressive, what they are saying about their motivation to move to Progressive, 80% marked caching offline or offline caching as the top reason to move to this implementation. eBay is among the early adopters of Progressive Web application, and I will explain why. Add to on-screen, it's another feature, okay? Heading this shortcut to your smartphone, adding like a link of a native app from the browser to your smartphone. It's a huge advantage and it's a very usable thing. And I will tell you also soon why. Think about storage, size of the application, response time, and all of these performance-related capabilities, but that's a teaser. Push notification also, quite a lot of people like this ability to get push notification from a web application on their smartphones, on their mobile devices like they get with native apps. I want to read everything here. This is just, and if you go to PWA Stux today and it's getting updated all the time, PWA Stux.com is an aggregation of case studies for organization who already adopted Progressive Web and what they see as a return on investment from doing so. As an example, I can read Best Western River North Hotel sees 300% increase in revenue with new Progressive Web application. This is just one example, there are plenty of more examples. If you want to try Progressive, I mentioned just a few. Twitter, Pinterest, Instagram, you can go to a website called PWArocks.com. It's being updated, Fleaboard. All these websites are adding more and more samples of Progressive websites. Google built an entire agenda about Progressive with full set of documentation, code samples, test cases that you can start using and learn about that. But still the testing is at the heart of this session. Testing of Progressive isn't easy, it's very challenging and I will explain soon why. Before I go to this slide, how many of you guys in the audience right now are looking at Progressive or learning about Progressive? Much less than the ones that are doing Responsive. From a recent survey that I did during a webinar a few weeks ago, 32% of the attendees and about 2,000 attendees were saying that they are looking today into Progressive Web. I met last month with Liberty Mutual in the US, huge bank, huge insurance company, and they are already investigating what does Progressive Web application mean to them. What are the benefits and whether they should move from Responsive, which they have today, to Progressive. Tinder, everyone who is dating, I'm married happily, I'm not dating but everyone who is dating must know about Tinder. And Tinder's seen in Android, look at the comparison of the native app versus the Progressive with almost the same set of features NKPB on their websites and cannot accomplish it because they are losing network. So in their implementation with offline caching that is being done at any given point when the network connection is dropping due to service workers and I will explain what is a service worker soon. Service worker, I'm back, service worker enables the application to store data and it's different between an iOS and Android, I will also show you what the difference is. So you can continue the journey up until adding to the cart, you cannot obviously do the payment without the network, but you can accomplish adding an item to the cart on eBay. Even without network in their Progressive Web application, once you get back online you can complete the transaction. And that's for them a huge advantage of moving to Progressive Web. That's a sample of Instagram, Facebook, everyone is using that. You cannot see probably the small text but that's the mark of last device in for time. So for my mobile device when I'm online it always like do some polling and offline caching up until I'm offline if you like. And based on that it can always preserve the state, preserve the session that I'm using on my mobile app, on the Android or iOS Progressive on my device. And what you are seeing here, and I will show you from a web browser so you can see it better. If I go currently to flibor.com, flibor.com and use a website that's a Progressive Web. Everyone knows the Chrome tools, it's by the way supported on Edge and Mozilla as well. For Chrome everyone knows the Inspect. When I go to the Inspect tool you will see that there is a special tab called application, maybe some of you are familiar with that. What's relevant for you in the application tab in regards to Progressive are two things. One is the manifest. Manifest like in an Android APK you have a manifest file, in iOS you have an info.plist which kind of describes the application. That's the descriptor of the Progressive Web application. It will identify the background theme, the colors, the launch URL. How you want when someone is adding the shortcut to his device, launching the Progressive Web, which website, which page is going to see the first time he's doing that. Icons, whether it's opening as a full browser or as a standalone application. Landscape versus Ported, you can define a lot of things in the manifest file depending on your implementation. You can test at home screen right from the Chrome tool as well. Think about that, it's just a descriptor. If you have a responsive web today and you work with your developers, your developers needs to know two things. One, they need to develop a manifest.json, a json file which defines the Progressive Web application. The most important thing, they need to develop separate JavaScript code for the Service Walkers. Service Walkers, you can also see them in the application. It's a JavaScript code and this is the core of the Progressive Web Implementation. This is what takes care of offline caching, registering for push notification, working with all kinds of events that are happening in the device like sensors activities and many more. This is a part of your implementation of your website and it needs to be maintained. This is why if you are switching from Responsive to Progressive, Manifest, Service Walkers, this will be your first steps to develop, to implement on top of your website. And you have tools like Google Chrome Inspectors and Edge Tools as well for Microsoft. That will allow you to do the basic implementation, the basic testing, it's not enough. This is how basically it looks. You can do some initial push testing here for the push notification. In Instagram, you will get an allow and decline push notification when you do that. You can click on push, you will see that the allow is actually being pressed on. If you want to see all the Service Walkers, you might have more than one, of course. In your Progressive, on Chrome, you go to a URL called Service Worker Internals. You will see all the lists that are running, all the lists of Progressive Web Applications Service Walkers that are currently running on your browser. And you can start engaging with them. You can get logs, you can stop and start. You can access that URL from here. So definitely Chrome has done a good amount of work to support the Progressive Web early days, early implementation and you can use that out of the box. So that's just in a nutshell the Manifest and the Service Worker. But the reality, because it's just new, there are a lot of bugs. I didn't want to put too many bugs. But you know, Instagram, I reported a bug, I think that they just fixed it two days ago, because two days ago the bug was still there. So there was a layout bug, we talked about responsive. When you add to iOS the Progressive Web application, two things happen. One, when you click on changing the language from English to a different language, the entire layout is messed up, you see the truncation, you see that everything is like shifting. That's not working well on iOS. Second, and that's a common thing across all Progressive Web application, working with third-party logins. Most of the web applications today have some kind of an integration, either to Instagram, Twitter, Facebook, LinkedIn, whatever, or other third-party. Preserving the credentials, whether I'm doing it using Face ID or just using a password, simply doesn't work. Each time I'm logging in to Instagram on my iOS device for the Progressive Web, it loses my entire credentials, I need to do it over and over again. Obviously, I'm not using that. It's a nightmare, so if you look at my device, I still have the native Instagram and still the Progressive, but that's an example on Instagram. This is Tinder, when you flip from landscape to portrait again, it's not really responsive. It should be, but it's not, so that's another layout UI bug. We're talking about some third-party login issues. We're talking about, I will soon show you some sensors, backward and miscompetibilities, as well as layout and UI issues. I'll just go in a few seconds again about the Progressive Web app foundation or the architecture. The architecture consists of two things. One of them is the manifest, the other one is the service worker, the JavaScript code that manages the entire core of your application. You can work with your developers, you can work with the internal tools later on to see that it works fine as implemented, but that's the basic for you to get started with implementing a Progressive Web site. The installation process is unique between iOS and Android. If you do it today on your Android and your iOS an installation of a Progressive Web site, let's take Instagram as an example. For Android it's going to be an APK installed on your device and a Chromium-based APK. It's not a traditional APK, it has a weird name that is being given and on iOS it's actually not an IPA at all. It's a subset of Safari with advanced permissions to sensors and other stuff, so you can think about some kind of a hybrid type of application, but again it's not an IPA and that's where the challenges begin. Why is that a challenge? We're talking about web across mobile and desktop. How do we test your responsive web today? Using Selenium. When you move from Selenium to a mobile device and you want to test some kind of a native application, Selenium cannot interact with the home screen of a mobile phone, especially not with native applications. This is where Appium comes into play. You need Appium, then QLR is here with us, thank you. You need Appium to launch the application, but this is not really an application, so today maybe I'm pitching it to you then and the community, there is a gap today to launch Progressive Web shortcuts from a mobile phone. And this is breaking the entire testing activity because you started on a desktop web, you then, the flow is, I go to tinder.com or instagram.com, I then go from my mobile device, I add it to my home screen, I then want to launch it, so it will launch in Safari or on Chrome if I'm running on Android. I cannot continue my flow, I cannot run it on a mobile device because I'm blocked to launch this shortcut. Once I'm able to launch the PWA on my mobile device, everything is more or less okay, still. There are push notifications, there are native objects from the mobile implementation of the Progressive that Selenium can still not interact with, but then you do have Appium, you have X, U, I test, and Espresso that more or less should be fine. So today basically you have Selenium plus Appium or X, U, I test, and Espresso. You bridge actually two different, they're closed by nature, but you bridge two different test framework to test one single application across desktop and web. That's a unique thing in the market today and you have no choice. So that's something that you need to know just to summarize. Two different types of installations, one is a shortcut of a Safari, subset of Safari browser on an iOS versus an APK on Android, launching it is a challenge. Okay, so I need to take this into account. I will show you how within Perfecto we solved it. It's a temporary solution, but we probably can work with the community and see how we can actually make it a generic solution for the entire Appium community. But life isn't easy. This is iOS versus Android. iOS today has different limitations with regards to PWA. I won't go to every line here, but from a storage perspective offline storage, browser based on Safari, it's less than 50 megabytes. Android is much more generous, 6% of your available storage. So if you have a heavy implementation of your progressive website, you need to consider these differences. You have different limitations across Android and iOS. It's not the same. In addition, if you work with advanced sensors like audio, this is, if you go to pwarobs.com, you can see a bunch of progressive websites. This is the voice memos. If you run it today on iOS 11.4, latest on an iPhone, you'll get this generous message that it's not supported. There is no way for a progressive to access the audio and record, take a voice memo. It works fine on Android. Okay, so this is another thing from a voice memory. Payment systems as well. Payment is not supported through PWA. On iOS, it's supported on Android. Android started a bit with Google, supporting that behind, started a bit earlier. Apple is catching up and it should be closed in the next couple of months. Edge with Microsoft are also making huge amount of investments to make progressive in line with all the other browsers as well. And I think they're on the right track. Let's move to test strategy. So this is for responsive. Everyone is doing responsive, so I'm not reinventing the wheel for you guys. I see for responsive web testing six key pillars. Everyone is using Selenium. It's fine. That's where we are today in Selenium Conference. For that, you need to have the right platforms. You build a Selenium grid, you have different devices, this is one pillar of your test plan for responsive, right? Then you have the visual. I've shown you how Tinder looks like when you do from landscape to portrait. We have applicles showing their visual testing. Visual for responsive is very important. That's the second pillar for success in responsive web testing. Obviously, the website needs to work. So that's the different navigation flows from one website, from one page to the other. And we see a lot of redirects. We see that from one responsive website and it breaks the entire user experience. Functionality testing of navigation for responsive is key for success. It's the third key here. Client-side performance testing. You are loading a lot of objects and I'm not sure if I have the slide next to that, but you're loading in the responsive website a lot of objects which should match the device screen size and resolution. Let's assume you're running on an Android small screen size. You probably only want to load the relevant images that fit and respond to that screen size in opposed to a large desktop. That's the different layouts that you use. If you load the full set of objects per each device, per each screen size and resolution, you're harming the performance. That's from a client-side. Obviously, you have the entire load testing that you need to take care of for web that's not new. Accessibility. Accessibility is something that people hate to talk about. I know that Manoj is here. Manoj is talking a lot about doing accessibility testing for web with Wave, with AXE. There are other tools that are used. Accessibility, I think, soon to become very much, I would say, mandatory for all web developers. So accessibility for responsive isn't different. You need to take care of it also outside, not just from the desktop web. It's responsive. So accessibility is the fifth pillar. And then you have the test environment conditions. Responsive on web is one thing, but responsive on mobile. When you are traveling, you are roaming. I have with me a colleague here, Wim, who is from Netherlands, Teletoo, who is challenged with roaming. And I don't know if it's responsive. It's a responsive, I guess. So testing network conditions, testing environments is definitely a key, is the sixth key. That's for progressive. If you want to test progressive on top of responsive, you need to make sure that the manifest itself makes sense. And the manifest has different parameters, different capabilities, like launching on stand-alone versus in the browser, different layouts, different themes, colors, icons. You need to make sure that the manifest is matching the user experience when you work on different devices and different platforms. That's one of the most important things, moving from offline to online, registering to push notification, working with this sensor that I talked to you about. So these two lines, these are very unique to progressive, but still you have also the additional capabilities. This is the third part, validate PWA-specific capabilities. What does it mean? I showed you the audio, right? Audio, image injection, voice injection, offline things. These are specific scenarios that are only relevant to progressive and only relevant on the mobile phone. Okay? So you need to extend your responsive test plan and add the unique capabilities that you will get from the progressive web implementation. So that's the third thing. Test across platforms inheriting for responsive, but still, this is different. I'm not repeating myself from previous slide. This is different because iOS and Android, you remember the table, behaves differently. So it's not just testing your smartphone on Android, you need to take into account the different limitations, like offline caching storage limitation, 50 megas versus 6%, and more sensor-related stuff, payment versus no payment, no payment support. So properly test across platforms with regards to progressive. Test automation and object strategy, I talked to you about thinking outside of your selenium head, taking selenium plus apium, maybe some visual tools, and you start to combine for one single application a bunch of test frameworks. Okay? And you only have one JavaScript source cost to test, but you need multiple test frameworks in that regards to have full test automation coverage. Google's PWA checklist. Okay? I gave Google a heads-up here and I think they are, I would say, some documentation from tools that allow you to start to get started with progressive, they have some push notification tools that you can use to test the push notification registry in progressive and many more. So I will run a bit faster here because some of the things I showed you, this is how a manifest and a manifest test would look like inspector in the Google Lighthouse tool. Google Lighthouse, this is where you will get the access to this manifest and service worker testing. You can see here some of the parameters that you can test, whether it's standalone versus this is the standalone implementation. This is how it looks like. On the right hand, this is the standalone display covering the full screen. The progressive will cover the full screen like a native application. On the left hand, it will be a browser-based user experience, so it will be the same content but display within a browser UI. So you want to actually make sure that you test for both. It's a simple configuration change in the manifest JSON file and you will see that it reflects and looks correct. Your end user won't do it, but if you want to support both, you want to make sure that both work and you can do it very easily with Lighthouse. This is the service workers. I talked to you about it. This is the Twitter light, how it looks like. You have full access to the JavaScript software through the JavaScript source code. You can test push notifications from here. You can analyze the code and get logs from what's going on within the Google Lighthouse and the service internals Chrome that I showed you in the beginning. So those are there. That's more like URL, so I don't need to remember. I put it in context. This is how it looks like. You go to Chrome inspect service workers, Chrome service worker internals, and you can start engaging, stop, inspect, unregister a service worker in a PWA application exactly from your Chrome browser. You don't need to write any code here. You can start doing it automatically from the browser itself. This is the specific capabilities of PWA, right? Google Maps, also it's a PWA application, so it means that it works with GPS, it works with location sensors. You need to make sure that these are working fine across all platforms, Android and iOS. So this is just zooming in into a mobile-specific capability that was inherited by Google under Google Maps Progressive Web application. So just think about web and mobile combined together and the test cases are actually growing in that regard. Automation is key here. This is one of the push notifications that you get allowing you to access a location, the permission form. This is the traditional responsive web in one slide. So taking care of the UI, this is not, this doesn't change. If you have a responsive and you implemented a progressive, everything stays. You have the same test plan for responsive that you carry, continue to carry on. It means UI and layout testing, performance, network-related testing, especially on the mobile front, functionality of the flows, differences between browsers, launching responsive from not just from the browser, you can launch today responsive from a link within Facebook. It's a different browser implementation. You also want to take some kind of a testing approach into that use case and now it's very common today. LinkedIn, when you go from LinkedIn and you click on a link which is a responsive web, you'll see it from the LinkedIn browser. It's a different UI, it's a different approach and you need to also do some kind of testing in that regard. Objects. So this is an example of, smaller peaks or something, that's a PWA application and what our R&D Imperfecto did and this is what we'll try to work with the community and see if we can do a mesh, we can push it to the community. We implemented because we couldn't launch using Appium, the PWA shortcut on the mobile device. This is done right now only for iOS but we implemented a new command called mobile.PWA start and stop and this enables us to bridge between the selenium test back to the mobile device after launching the shortcut on the iOS device. Without that we couldn't actually do automation in one flow. You can think about using web, sorry visual object as well to launch and just do a click based on OCR on the icon instead of using Appium and then go back to your selenium coding it will also work. But if you want to do coding in Appium and stuff continue your selenium scripts as well you just want to have mobile PWA start which gets the application name and smaller peaks in that regard and it will work fine. Again we'll see how we can push this to the entire Appium community so everyone is marching towards PWA can leverage that it's not a big change but it's one. And that's how it works. That's I have a sample project in Appium that if someone is interested I can share with you and to end it's for flipboard flipboard.com but with this implementation already it works if someone is interested I have it installed on my IntelliJ I can actually show you. I'll step forward from that from that point. So just to summarize the previous point selenium plus Appium maybe some visual testing as well this is what it takes today to do test automation of progressive web and you have these six plus six buckets that I'm recommending take the responsive buckets that most of you I'm almost sure are familiar with add to them the unique things that progressive is bringing to the table and you have a new test plan which is suitable for the future I want to give us the six element here before I'm wrapping up the checklist from Lighthouse you go to Google developers.google.com progressive web app checklist this is a good first step for you if you build a test plan for progressive and you want to ignore all the bullshit that I talked about you start from here they will give you a list of things to consider and some recommendations on where to look and what to look for both from security which is important and a consent for many enterprises today especially large banks who are marching from native to progressive they are concerned about security in the web marching from web to mobile so it's a concern Google actually addresses security as well here accessibility testing service workers testing manifest files and all these extensions for Lighthouse that you can start working with so I strongly recommend look at that as well summary so progressive application today is growing I mentioned brands that almost anyone here is familiar with Tinder, Pinterest Instagram, eBay Flipboard the list goes on and on everyone understands the benefits of adding native mobile capabilities to web even though the maturity between the different mobile implementations and the browsers on iOS and Android are different it's the gap are getting close I don't know what are the plans in iOS 12 the new Safari and the new operating system implementation I'm sure that you will see more advanced capabilities coming and closing gaps in progressive as well there is a large community and large threads that I'm reading all the time in medium.com just on iOS 11.x with progressive I recommend for you to subscribe to that chat and stay in touch with what's going on there it's very live and kicking Selenium visual testing and Appium that's my strategy so that's the huge change here if up until today responsive could have been completed test automation could be completed only through Selenium plus some manual testing today you need to think about the mobile extensions of progressive and this is where Appium and maybe some other visual tools that are unique to mobile will provide you the added value that you are missing today again leverage what you know today it's still Selenium it's still Java JavaScript so continue leveraging what you know today but think outside of the box think more about user experience offline scenarios network push notification try to bridge mobile and web techniques into one with that I would like to thank you for being here and if we have time I hope we have time for some questions I'm ready to accept them .