 So, today we are going to see, we are going to discuss about dealing with locators across browsers. Is there any better way to do that? So, as you can see, there are three matter the most in cross browser test automation locator, locator and locator. So, how many of you had issues dealing with locators especially across the different browsers? So, do you all agree that locator is the main issue that you usually have a lot of problems dealing with? So, the question remains, how do you find the right one? So, here is the agenda, learn best practices to identify the ID locator for automation. Let's see if it exists, learn how to solve the challenges with picking the right locator for each browser and version and learn how much time could be saved in implementing the recommended solution. As you all know, right? Selenium uses locators to find and match the elements of a web page that it needs to interact with and locators are unique identifiers for one or more web elements on a web page. So, Selenium offers various strategies that you can use to locate web elements starting from ID, name, tag name, XPath, CSS, etcetera and each of which has their own pros and cons, advantages and disadvantages. There are various situations wherein something might be of more help than the others. So, we are not going to discuss each of them. I am pretty sure that you all already know about that. So, at a high level, locators can be categorized into structure based and attribute based locators, structured based, you know, they rely on the structure of the page to find the elements. So, like XPath, DOM, CSS, etcetera. So, whenever there is a change in the page structure, your locators may become absolute. And attribute based locators rely on the attributes of the elements to locate them, like identifier, ID, name, link and again CSS, which basically has good balance between the structured based and attributes based locators. So, let's have a quick view of the pros and cons of one or two locators. So, the first one being the ID is the most specific one that can help locate an element on a page and they are more reliable. So, as long as the developer doesn't change the ID of an element, it is not going to change. So, you are depending on the ID. But the downside of it is, you know, it doesn't ensure that it's unique on the page. So, it depends on the discipline of the developers and if they don't follow the practices, it may fail. So, maybe while recording, you may be, you know, your target element may be the third or fourth locator that has the same ID, but while running, it will pick the first one. And most dynamic apps, usually the, you know, database debent ones are dynamic apps, wherein the content is added dynamically to the pages. Locators are unpredictable. IDs. So, it may not work in all the cases. Similarly, if you come look at the X path, so because it is structured based one, any changes to the structure of the HTML will invalidate your locators if they are using X path. Right? The changes are expected and especially when your application is in development stage, you know, developers, you know, they change, they keep changing the page, right? Because the, no design is final, right? So, they keep improving the page. The structure is not fixed. And X path can be passed in both the ways, top to bottom and the other way. And X path is not resilient enough in situations where development is progressed. Yep. And the third one is CSS. It's the fastest and most flexible and the browser themselves use them for applying styles. And it gives good balance between using structure and attributes to find the elements. So, what it means is, say, suppose you have, say, username, password inside a form, say, for example, in a login page. So, though the structure of that changes, as long as you maintain the form itself intact, right? You can move that around and have your CSS locator, say, you know, within this ID, the form with this ID under that, this one, right? So, even if the structure changes, you can use CSS to bring the resilience into your locator identification. Again, there are two ways where you can locate elements on a page. So, you can use tools like Selenium ID and then prepare your test cases, your scripts. And you can test the automator script in different browsers, check what are locators work in, for which browsers, et cetera. So, if a locator works in most browsers, but not all, then use a specific different locator for just some browsers and versions. So, this takes some time and you need to, you know, give some pilot error and, you know, move back and forth between your implementation and recording your instructions. And the other one is the engineered locators. So, this requires QA engineers or test engineers to spend extra time with your developers closely to understand the application, analyze it, understand it, and work closely with them and use various tools to identify all the available locators and then see which one suits in that particular situation. So, maybe, you know, IDs may not work for the dynamically generated content that you intend to add to your applications. So, this trial and error still exists. But because, you know, you're working closely with developers and identifying upfront about, okay, you know, which one suits better in this situation, okay, let's not go with this. You know, or maybe, you know, your HTML structure is fixed and, you know, you can use XPath in that situation or you can use CSS. And when you have Nestor relationships, engineering a locator works better. So, all this process is a little more time consuming, but it's more resilient when compared to, you know, having locators recorded and, you know, then go to your implementation and then check whether that particular location works across the browsers or not. Let's see an example. So, a recorded locator could look like this XPath, which translates to search for a button, which is the second element of the third element of the due, which is, again, second element of the main. So, as you can see here, as long as the structure is intact, it works. But if the HTML changes, right, the locator is gone. So, engineered locator would look something like, you know, okay, this is the element with the disk tagged and the identifier. It's a button with ID so-and-so, a span with the class so-and-so. So, we found two ways of doing that. So, the challenge is not all locators work in all browsers and versions. Not all locators do the job in the same time in all the browsers. Same locators, some locators require more rework from developers. They need to spend extra time effort, which translates into additional costs. Some locators are more resilient to changes to application over time than others. So, which locator gives the biggest bang for the buck? So, it's the one that helps reduce the script maintenance and reliability. Is there anything else? Any questions so far? So, currently, to get the most of the existing solution that we have at hand. So, okay, you know, this is our experience. So, I'm going to share. So, we tried to work on this problem by adding additional conditional logic. Saying, okay, you know, if this is the browser, then do this. Pick this one. So, we need to do a lot of trial and error going back and forth and then, you know, identifying different locators that works for example, for a long X path in IE, it takes a lot of time or fails most of the times. So, we need to have conditional logic per browser and that is additional work, right? And it's two time consuming. So, we tried for a better alternative. So, the alternative that we came up with is try all the locators until at least one succeeds. So, we tried to record all the locators that are available for a target element of print. So, we used our own proprietary, I mean, IDE recorder that works on top of Selenium that can record all the available locators initially and saves them in an XML that we use for storing the scripts. Basically, all the instructions which have the command, target, and value. And not just one target. So, we try to save all the available locators into the XML itself. And if you're programming, so this is the recent addition to the source. So, I'm not a Java guy. So, we haven't tried it much, but last minute addition to the presentation. So, it claims that, you know, you can use find all annotation in the Java page factory and that will do the job for you. But this is at the run time, execution time. And this is while recording the script, right? And during execution, you can loop through the available locators, taking the first one, try it out, if it fails, go to the next one. So, do this until all the locators fail or at least one passes, succeeds. So, from the IDE side, if you're using IDE to record your scripts on locators, like the Selenium IDE, it captures all the locators, but it only stores the one that the user has, the one that he switched to last. And if you save that script and then open it again, so you have only one locator. Once you find the element again, find all the locators available. So, the change that we suggest to the community is, makes Selenium IDE record all the available locators of the target element and something like, you know, this is an XML structure that we internally used, so that saves all the available locators of rent. So, the possibilities at the execution side are endless. So, you can fine tune or, you know, improvise on finding the locators and making sure that the test scripts are not failing just because it couldn't find the locator. So, again, this is the format, the find all annotation will take all the locators found by various find by annotations, it can encompasses and then returns them all in one list. So, this is a recent one year back edition. So, we haven't explored it completely, so some of you can continue. And let's see some pseudocode. So, here we are, this is just a snapshot of at a high level what we can do. So, pick each locator one by one and then see if you can use it. If it fails, go to the next one available in the list. So, the benefits of this approach is you don't have to predetermine the optimal locator and all locators by browser and version. So, you can save going by, you know, doing trial and error, going back and forth and you know, you can save time there. And it gives more resilience to your scripts as your apps evolve. So, what's beyond is you can find your execution automatically based on the user preference and past execution results. So, what that means is you can switch the order of the application of locators based on the past or fair result. And you can switch the order of the application of locators based on past execution time as well. Because not all locators take the same amount of time in all the browsers. So, you can pick the locator that was faster, say when both of them are working and you can skip the application of subset of locators. So, the forever perfect locator still remained a myth. So, there's no perfect and unbreakable locator because apps evolve, browsers evolve and locators break. So, developers experiment with UI design, streamlined HTML and fixed bugs and HTML changes in apps make locators incompatible over time. And again, the cost of maintaining locators is considerable. That's it. So, how do you think the performance is going to be affected because of this? We'll only go for the next one when the first one fails, right? While recording, yeah, if you're manually doing that identification, right? It may be time consuming. But if you, in case if you're using Selenium ideal like thing, you already have all the locators available. Yeah. Locators remain same. Some locators work, some locators may not work in the same pose. It's not good for you much, it's paid out. But then you get the consistent result, you want to understand the result. Thank you. Thanks a lot. So, Sanger was saying in his keynote that the Selenium IDE is going to be deprecated as of whatever, G3, so no more development. So, it looked like the community was going to make that change. It would have been pretty fair. So, it looks like that could be December-ish. This is a definitely best idea. Well, we well switched the build out, yeah. It's not like we're removing the code file. Yes. It's the reason they're switching, oh, they're assignment there. They switched the build out because the code is quite different in IDE, right? But you would still use it if the fix was in IDE. It's still a recall of flybacks, but it's still a fade-in. I already said a lot. Well, the Android is a code that I've documented before, so did you, did you find a way to improve it? Yeah. Yeah. I think this was the idea, so, but the precedent hasn't been worked out. The reason Selenium IDE, the retention of the utility is generally, this union is very low because the way you choose the selectors is globally less than what humans in years can decide in certain cases. So, did you find a way how to use, then use multiple selection with components? So, yeah, components are components that are components using the selector. How to find this one? It's not generally quite confident. It's going to be captured on possible readers on the IDE, the IDE which we are building. And we can give you the random options which you want to pick. Basically, if you know about your application and you are sure that the IDE is going to work on it, it never will work. You can disable that option to search for it. So, we will take the presence out from particular session. We go with X path, but confident-wise we are not capturing it. Yes, while recording, we never know what type of component in your point of view, in application point of view. Whether you're talking about search grade, as an automatic recorder won't understand what is the component, right? All it knows is, it's an element. It's basically a component, web component. But automatically, if we take a decision, but it may not be a genuine decision. Is there a way to validate X paths in IDE? Let's say for Firefox, I have a fire path. There's no kind of stuff for IDE. So, the problem is I have a thousand plus test list, which is completely working fine on Firefox. The same thing I want to validate on IDE. That's the reason why we have the solution, right? The question is, is there any way to validate X paths in IDE? If you want to know the X path of the component in IDE? There is no way. I am such a person, that's many times, but I never find any solution. It is not a good idea. Since Excel sheet, they have written some macros and they'll give you this ready-made X paths for IDE. You can open your application in the Excel browser and just point it out and it will give you all the possible combinations of X paths, CSS, and locators. Nice. How do we locate that way? It's a macro, which will open its internal browser and you can open the URL in that and do the same stuff. It's not that great, but it works for initial things like we do with Firefox IDE. Nice. How do we get that? It's from Google code. For what its name, I'll try to find out. I have it. Thank you. Thank you, everybody.