PQA Panel Talks: The Creative Art of Locators

PQA Panel is back, and our host Mike Hrycyk is sitting down with two PQA’s Automation Testing Team members, Shobana Muhilan and Jordan Coughlan, to dive into using locators in automation testing. Together all three panelists share how through time and experience, they have come to find real satisfaction in the challenge and creativity of making and finding locators in automation testing.

 

Episode Transcript:

Mike Hrycyk:
Hello, everyone. Welcome to another episode of PQA panel talks. I’m your host, Mike Hrycyk. Today we’re gonna talk about automation locators with our panel of testing experts. I think this is a really good topic for us to dig into, because we’ve sort of talked in general about automation, and sort of specific tools and things like that in the past. But we haven’t really started to dig into the weeds of one particular area. And I like locators for this because there are a lot of different ways of handling locators. There are a lot of different technological hurdles in it and the stuff you read out there on the internet is just up and down around it. So now I’m gonna turn to our panel of experts and let them introduce themselves. So Jordan, please tell us about yourself.

Jordan Coughlan:
Hey, I’m Jordan Coughlan, I’m on the automation services team here at PQA. I’ve been here for a few years now and I’m based out of Fredericton.

Mike Hrycyk:
Thanks, Jordan. And now Shobana, please tell us about yourself.

Shobana Muhilan:
I’m Shobana Muhilan and I’ve been working on QA automation for almost 10 years. So I have completed my master’s degree in computer applications. And then I started my career as a developer in BA data warehouse tools. And later I moved to this automation testing and I have been working in PQA for almost 2 and a half years and from day one I’ve been with EQ bank.

Mike Hrycyk:
Thank you, everyone. I’m sure this is gonna be a very interesting discussion. Well, let’s start with just the basics. What is a locator? Shobana do you want to give us your definition?

Shobana Muhilan:
So as quality engineers, we all know that testing any UI based application, it involves user actions such as click, type, select on UI elements. So now the question comes how to do test automation tools. Like, how will my automations identify UI elements to perform UI actions? So the answer to this is locators. So locators are used to uniquely identify or to match UI elements based on element properties. So XPath, it’s an XML path which has a syntax or a language for finding any element on the webpage using the XML path expression. So it is used to find the location of any element on a webpage using HTML DOM structure. DOM is nothing but, it’s a document object model, which is an application programming interface for HTML and XML documents.

Shobana Muhilan:
So just, I want to add a few more points here. Application UI elements are developed by having certain properties, which include element identifier typestyle, text, label, element, index, ecetera. So these element properties, like we can use all these element properties as locators. So we can differentiate do web-based application and a window-based application as well. So for web-based applications, we can use XPath, DOM, CS selector and for window-based applications, by default, they’ll have some native libraries or custom actions. Sometimes they’ll have some DLLs to locate UI elements. So DLL is a dynamic link library, which contains code and data that can be used in more than one program at the same time.

Mike Hrycyk:
Awesome. So my next statement is maybe controversial, but this is something that I’ve learned. Why are locators so brittle? Are they brittle? Maybe I’m just talking outta my hat. Shobana?

Shobana Muhilan:
Yeah. Locators brittleness, it occurs mostly because of not following frankly development best practices and processes. Like favouring automation, any front-end code or changes that impact locators’ strategy fall within automation. Some of the entry points, which causes brittleness, while automating, are a dynamic identifier generation, which is a random identifier, they used to give some random IDs. And the second one is element property change made by developers. And the third one is browsers specific implementation, which causes different UI element hierarchies. So it depends on Chrome browser have different setup and IE, those that can have a different setup based on these things I find brittleness occurs.

Mike Hrycyk:
So I mean, one of the things I see, so I really do believe that IDs that are unique and consistent is a really good way to go because then you’re assured. But a lot of it developers do go with the randomness or sometimes they call ’em Dynamic IDs. Do either of you have a technique you use with developers to suggest that they shouldn’t do that to make it better for automation?

Shobana Muhilan:
Yes. Right now I’m working on a project. So even they have the same setup, the IDs will be generated based on the number of pages they will be loading each time. So the first time when they’re open, it starts with 1 0 1. And next time when we open the same page, it’ll start with maybe 1001. So that is a little difference on that. They don’t have any unique ID for a particular element it’ll be generated based on loading the pages, which time we are loading the page. So sometimes it’ll be really hectic.

Jordan Coughlan:
Yeah. Sometimes too what you end up having to do and like that is finding an element that is uniquely identifiable. And then even though it’s not the one you’re looking for, you can locate your element relative to where that one is on the screen,

Mike Hrycyk:
Which itself seems fraught with brittleness and peril. But I mean, in the end you do what you have to do. So Jordan, have you ever spent some time trying to talk developers in a project into moving towards uniquely static identifiers so that it works better for automation?

Jordan Coughlan:
Yeah. It never hurts to ask. And sometimes they don’t mind adding them in for you other times it’s a change that’s going into code and they really don’t wanna make it unless there’s an absolute need to. But I’ve been on projects before where there’s been a compromise where I’ll come with a list of elements that I would like and an ID added to and then get them to add it in.

Mike Hrycyk:
Awesome. Shobana, do you have anything to add there?

Shobana Muhilan
Yeah. In one of my projects, which is an agile development, so developers are working with us. So in that case, if there is any miss match, we talk with the developers and they will change it immediately. But some projects, like we used to purchase a project as a third party tool. So, in that case, there is no other option. We have to find a different workaround for that.

Mike Hrycyk:
And that’s fair. I mean, sometimes with third-party tools, you really have your hands tied. There’s just not a lot you can do about that. Okay. So we understand that there’s the automation tools we’re talking about. Maybe some of it’s inbound or integrated with that, but what are the tools that you’re using when you’re working with locators?

Jordan Coughlan:
Yeah. So if you’re coming up with your own like XPaths, I mean really the only tool that I’ve ever used is DevTools. Referencing that and sort of spinning my own out, but I’ve also used quite a bit of TOSCA over the past year and it’s sort of handles a lot of that for you. You don’t really see the locator at all, hidden in the background.

Mike Hrycyk:
Do the DevTools help you find IDs as well? So it’s not just XPaths, will they also help you find the IDs to reuse?

Jordan Coughlan:
Yeah. Well, you sort of just go through the HTML yourself.

Mike Hrycyk:
Right.

Jordan Coughlan:
Yeah. Like DevTools will generate XPaths for you, but they’re not very good. Usually, they’re pretty fragile. They might work once.

Mike Hrycyk:
Shobana anything to add?

Shobana Muhilan:

So there are many open-source browser extensions available when your working with locators. By using XPath and CSS as Jordan mentioned. But the following are some of the browsers specific tools available in the market right now. So for Firefox, we could use Selenium IDE or FireBug, and there is one more called FirePath. And with Google Chrome when we press F12 key like we can use the browser developer tools to develop locators. And there is even for IE browser, it has an inbuilt developer tool, which has CS Selector. And there is one more like if you want more functionality with IE too, then we can use Fire IE Selenium, which helps with XPaths.

Mike Hrycyk:
So maybe I’m showing my age here. Does anyone use Fiddler anymore?

Shobana Muhilan:
<Laugh> not really

Jordan Coughlan:
Never heard of it.

Mike Hrycyk:
I’m totally showing it was the tool like 10 years ago. Okay. So definitely showing my age and when I’ve done hands-on stuff like that. So there we go.

Jordan Coughlan:
Just one more thing. Any XPath or, locator that’s generated by some program, you gotta be careful using them cuz well, at least in my experience, they don’t, they’re not very robust.

Mike Hrycyk:
So you’re raising a question for me here then Jordan. If I don’t have a unique ID and I’ve decided that what I need to use is XPath how are you about using an XPath the most reliable way? What’s the most reliable path, if you will, towards using your XPath?

Jordan Coughlan:
It sort of depends on the application itself. You know, you start looking for other unique identifiers other than the ID that you can plug into your XPath. So might be able to use a class name or text. Although both of those are, they may or may not be good options just depending on how often you’re expecting them to be updated or changed. You sort of have to think about the context.

Mike Hrycyk:
So Shobana, anything to add?

Shobana Muhilan:
Yeah. Actually, there are two types of XPath. One is an absolute XPath and the other one is a relative XPath. So absolute XPath it is the direct way to find the element. Like we had to give the parent towards the children. We had to give an order by using a forward slash. So if there are any changes made in the path in future, so then that XPath it’ll fail. So in that case, we can use relative XPath. Relative XPath starts with a double forward slash which means it can source the element anywhere on the webpage. For example, we can give the ID is like something menu. So we can just give an ID, go to the menu. It will try to locate at the ID, This is equal to searching for the menu in the whole webpage. It won’t go through the parent to children in this path. It doesn’t have any exact path, but we can find the element directly by using relative XPath. So normally we used to prefer relative XPath, as Jordan said, sometimes because of the absolute XPath, it is really very brittle because of the HTML DOM structure will impact the locators.

Mike Hrycyk:
So the picture I’m starting to develop here is that with XPath or with all locators, there’s no hard and fast rule. You couldn’t write me an instruction page or sheet that I could hand out to my automators and say, yep, just do this every time. It’s really, you have to look at it, find the way that the system is built and what locators you can make. And even on the same page, you might end up using different types of locators depending on the function that you’re trying to test. But would you agree to that Shobana?

Shobana Muhilan:
Yes. Yes, that’s right.

Mike Hrycyk:
<Laugh> That sounds frustrating.

Jordan Coughlan:
And there’s more than one way to go about doing things as well. Like if you give two people the same webpage and say, “oh, automate this functionality”, I’m sure that you’ll get two different answers at the end. Right?

Mike Hrycyk:
I guess, well, so sometimes you could tell that like, oh, this isn’t a very good path. This is not a great path. But I expect that sometimes you can only tell by analyzing over time, which ones would be more brittle. So we touched on Tosca a little bit. Jordan, you mentioned Tosca and, how it does it. Let’s talk a little bit between the different automation solutions that you’re familiar with. Just how does accessing and using locators differ. Let’s start with you, Jordan. You can start with Tosca and then, I know, you know, a couple more, at least one more automation type. Let’s talk about that a little bit.

Mike Hrycyk:
Yeah. Well, Tosca lets you scan like a webpage and you scan a webpage and then it’ll spit out at this huge list of elements that it found. And you basically just put a checkmark beside the ones that you want to use, but it hides a lot of how it actually locates that from you. All it really tells you is whether or not it’s uniquely identified or not. And if it’s not, then you’ll have to find another element on the page that is uniquely identifiable and link the two so that it can find it relative to the other one. Did that answer the question?

Mike Hrycyk:
Yeah. So, and I think based on my own limited knowledge of Tosca, if it does break, there’s a function where you can rescan and then pick it again. Right? So it, it can reset and, find it again. And that’s relatively easy. I don’t think it auto rescans it sort of prompts you is that accurate?

Jordan Coughlan:
Yeah. You guys still have to make the decision.

Mike Hrycyk:
So now pick, so that’s, how it works in Tosca and now pick a different automation tool that you’ve used. And how is it different?

Jordan Coughlan:
Yeah. Well if you’re doing something like Selenium, it’s really up to you to go out and find how you wanna locate. It’s really, it’s not that different of a process. It’s just more hands-on.

Mike Hrycyk:
You’re doing all the definition, investing yourself in Selenium. Okay. So, Shobana, anything to add to that or any other tools that you’re aware of that handle a little bit differently.

Shobana Muhilan:
Yeah. So I’m working on UFT automation, so which is a window-based application. So I can see a difference like Toscas is really very good if we need one with little less scripting and it’ll write the scripts on its own. That’s what I heard, but I have never worked in Tosca yet. So I used to work with UFT. UFT tool is a license version so many people, they don’t to get this too, But the other thing is we can utilize more functionalities with UFT. If we need any help, we can get support from UFT team as well. But for UFT, we need to write all the scripts line by line like it is developed in VB Scripting. So basically we had to write all VB Scripting. UFT has a unique spine which is a locator. So there we can just grab a spine and then we can find the element locators.

Mike Hrycyk:
So with UFT are you saying, “Hey, I want this button, tell me what my possible locators are.” Is it like that?

Shobana Muhilan:
Yeah. So what will happen is like Selenium, when we press the F tool key, we can see an arrow which will just, we have to drag that arrow. And then we had to place for a particular element. For example, let’s think about a textbox. So if I drag the cursor to a textbox, then we’ll get the property of the textbox. In the same way, even in a window-based application with UFT, there will be a spine in the UFT tool. So just we had to click the spine tool. Then we’ll drop it in the textbox. We’ll get all the properties of the textbox. And based on the properties, then we’ll find the locators and we’ll click or enter some data, whatever you want, we can enter through it.

Mike Hrycyk:
Okay. So really again, the picture we’re building up is there’s a lot of differences and you have to learn how to do it for the particular solution that you have in the particular problem that you’re attacking. But at least I think the base concepts are all the same

Shobana Muhilan:
Yeah, that’s true. Yeah. And with UFT, I have a lot of experience in UFT compared to other tools. So I have given a lot of workarounds in UFT based on VB Scripts. So even in like whatever things we have to connect to towards Excel, then we can write a VB Script to launch everything. We can do it in UFT

Mike Hrycyk:
So I think we’ve talked about this a bit, but let’s start with you Shobana. Tell me what you do if an element does not have a uniquely identifying attribute?

Shobana Muhilan:
So the biggest obstacle with locators is getting developers not to use dynamic ones, right? So in that case, I can tell we had to calculate the ID of a dynamically changing element using relative elements. I could give an example here, like, as I told you in the beginning, like for a web page, the title of the page, it has some unique ID. This means the text is equal to the name of the title. And based on that, I can give a different related element or, for example, I’ll have like 10 text fields. So I can calculate based on the relativity with the title of the element. So that is the first thing, we can identify the element, which is not changing at all. And then based on that ID, then we need to do a quick smoke test to verify whether the relative element exists or not for that purpose for the first time. And then using this unique property, the developers, in the case of buttons, can also get the name of the button whether it is enabled or focused in that way. Yeah. Based on that particular ID, we can enter the relative path. For example, ID for the title ID. The ID is like, 0 1. And, r the text ID, I’m going to use 310. So I can find the difference between these two, like 310 minus 3, 3 0 1. This is one of the ways that we can handle the dynamically generated IDs.

Mike Hrycyk:
All right. Cool. Anything to add there, Jordan? How do you handle an element that does not have a uniquely identifying attribute?

Jordan Coughlan:
Yeah, you sort of have to be a little creative. And I think as Shobana said, you have to find it relative to another one is another, probably the first good option. I mean, there are other things you can look for. Like, you can identify it by text sometimes. Sometimes that’s a good idea. It just depends on if you expect text change or not, but the same problem with locating it relative to another. There are a bunch of ways to do it. It’s there’s not really a right way for all cases.

Mike Hrycyk:
So if you’re writing good code in your automation, when you go, I was about to say off-script, but when you’re using different than, I mean, anytime you’re picking a locator and it’s just not obvious is how you’re doing it – do you have special ways of documenting that to someone else who’s maintaining that code? Who’s working on it when it breaks is going to be able to understand just how you got that located? Or is it, is it always obvious? Am I just off track? Let’s start with you, Jordan.

Jordan Coughlan:
I don’t think so. I might put in the little comment if I expect it to break or be flaky, but…

Mike Hrycyk:
Do you have experience of managing or maintaining someone else’s automation code where that became a problem for you or, extra difficult?

Jordan Coughlan:
Oh yeah. But when the automation breaks, it’s usually pretty obvious where broke, right? Like it’ll get so far and you’ll get an error message that says it was unable to locate some element. So it’s not something that’s hard to find when things go wrong.

Mike Hrycyk:
And, maybe your fastest path at that point is really just to rediscover the element in your own way and then move forward?

Jordan Coughlan:
Yeah, I would say so. Yeah.

Mike Hrycyk:
Awesome. Shobana, do you have anything to add?

Shobana Muhilan:
Yeah. Especially whenever there is a new change in the whole application. Like as I’m using window-based applications, they used to change with the version names are. So what will happen is whenever we try to identify the page title, page name, they’ll be adding with 0.1 0.001. Something with a version name. So in those cases, we have to be very careful, as most of the time I’ll be using regular expressions. So in future, if someone is going to add a locator, then they have to be noted earlier. So I use a maintenance sheet for future automation testers. How they have to follow the same structure. Especially for dynamic IDs and how I’m going to click if it is not going to recognize then how am I going to implement with a new workaround? Even those points, I will try to add it in a document so that the future testers they’ll have a look at it.

Mike Hrycyk:
Okay, good. Let’s shift things a little bit. So Shobana starting with you. Can you tell me about a time when you came up with some clever way of getting a locator when they were being challenging?

Shobana Muhilan:
So my early project involved verifying UI elements within iframe loaded from different domains. So these iframes are used to embed another HTML document from a different domain, other than the application domain, like a third-party integration. So we can see on a top sometimes it’ll appear as a popup, enter the first name, last name, or maybe like in my previous project, we used to, get driver license information. So it’ll be a particular interface and it’ll pop up from a different domain. So this is a third-party integration. It is a web browser and it does not allow interacting with iframe loaded from different domains. So I had to create a new Chrome browser profile to disable those web security, which helped me to validate third-party functionality.

Mike Hrycyk:
I don’t see iframes very much anymore. Is, that accurate? They’ve sort of gone away unless you’re working on a legacy site?

Shobana Muhilan:
Yeah, it’s been a very long time. I was working for a state project for the unemployment division. So it has to contact with three different interfaces. One is with employment, zone and driver’s license. It has to get the details of the license. So it has to contact the different applications. So in that case, yeah.

Mike Hrycyk:
Yeah, I’m familiar with them from the same timeframe when I used Fiddler. So maybe that does indicate how old they are.

Shobana Muhilan:
Oh, <laugh>.

Mike Hrycyk:
Jordan, do you have an example of some time you got really clever in figuring out your locators?

Jordan Coughlan:
Yeah. I remember there was an application where you come to the page and, what you wanted to do was click a link that was hidden in this tree structure, right? And when you first come to the page, it would be completely collapsed. But if you expanded one of the nodes, left the page, and came back to it, it would remember that you had expanded it. That’s sort of annoying. Anyway, I couldn’t for the life of me, figure it a way to tell whether or not a node in the tree had been expanded or not. There was a little arrow icon to it, but there was no way to identify whether or not it was already open or closed. So what I did, after some struggling, was realize I could use an image of the collapsed icon search for all instances of it and just click each one of them to expand the whole tree out and then find my link that way. Yeah. I felt pretty smart.

Mike Hrycyk:
<Laugh> That is a little clever and, I expect also a little annoying and time-consuming in terms of not just writing your code, but when you’re running the tests that would add, I don’t know, two, three seconds of, of that expansion.

Jordan Coughlan:
Yeah. Wasn’t that bad really.

Mike Hrycyk:
So I mean, you’re both automators by profession for the most part. Is finding those little challenges like that and overcoming them, like every time you’re gonna find a challenge like that in overcoming, is that one of the high points of why you love automation, Jordan?

Jordan Coughlan:
Yeah, absolutely. I mean, it’s really frustrating to encounter a problem like that. That’s, you know, you might spend all day sort of just bashing your head against the wall, trying to figure it out, but then finally getting it to work feels really good.

Mike Hrycyk:
Awesome. Shobana?

Shobana Muhilan:
Yeah. Same thing. If you figure out some issues, then we don’t sleep. It’ll roll in our head for a long time. And finally, once it is resolved… Yeah, you feel so happy.

Mike Hrycyk:
I think – so this is one of my prepared questions and I think that really, we sort of answered it already, but just to make sure when is it suitable to use text on the screen as an identifying property for a selector expression? And I think I know the answer, but I’m gonna ask you guys. So, Shobana?

Shobana Muhilan:
Sometimes like the locators are pointed directly, especially during the output. Like sometimes we will be expecting an output. For example, particular User 1 has admin rights. So this User 1 is what we have to enter through an input and the output would be administrator. So, this has to be captured as a text. And then we usually get it during the run time. Like what is the result of this? What is the text of this particular locator? Then based on run time, if the text is equal to administrator, then we have to follow this set of rules and regulations like you can do this kind of thing. And if it is a regular user, then we can follow these things. So I have used it in that kind of thing. And even sometimes when we want to print the output values, in that case, we have to call the text. If it is a textbook, then what is a text located in that particular textbook? So we use it to call in that view.

Mike Hrycyk:
So I think I’m getting that text is a necessity and assertions and validation to make sure that the responses you’re getting are, are accurate. But are there instances where you’re using it itself as a locator to find the element on the page that you want to use? Or is it just never useful that way?

Shobana Muhilan:
Yeah. Yeah. We’ll be using that for it depends on the developers. Sometimes they will give the unique ID to class name, or sometimes they will prefer to give us a text as one of the property. So in one of my project for the project, they used to give unique property and a text. So it depends on the developers. So in that case, then we are to use only text as a unique ID.

Mike Hrycyk:
Right. And I presume text is one of the most brittle options though?

Jordan Coughlan:
Yeah. It’s like a last resort. You never really wanna choose text as your first option, but as long as it’s predictable, then you know what that, the text you’re searching on is then I don’t see why you can’t use it

Mike Hrycyk:
Using the obviously factual method of on the spot, statistical creation. Jordan, if you had to break it down, how much of the locator code in your automation, as a percentage, is done in the really good, unique ID way versus the really unstable way? Just ballpark?

Jordan Coughlan:
Yeah. Oh, it would be impossible. Cause it depends so much on the application that you’re writing the automation for, right? Like, I mean, if the web app has an ID for everything then 100%.

Mike Hrycyk:
Yeah. Right. But, so my question is how often are you working with a web application that has those IDs set as unique identifiers?

Jordan Coughlan:
Oh, it’s hard to say maybe 50% of the time <laugh> as just like the middle ground.

Mike Hrycyk:
Oh, that’s way higher than I expected.

Jordan Coughlan:
When they’re there it’s not something I think about it’s when they’re missing, that really stands out in my mind because it’s so much more painful. So yeah, I don’t think I can give you a good answer percentage wise.

Mike Hrycyk:
That’s what you get from on the spot statistical generationShobana, do you have an idea?

Shobana Muhilan:
Same as Jordan. Yeah. It’s like 50%. Like it will take more time. Like if there is a static IDs for everything. For every locator. Then it is like our project work is so much less. I would say this locators, it will occupy 50% of the work. That’s true

Mike Hrycyk:

Coming up on time here. So I’m gonna wrap up with one question. Same question for each of you. If you had one trick or a couple of tricks that you’d like to tell our listeners about that would make their life with respect to locators better, what would that trick be? So starting with you, Shobana?

Shobana Muhilan:
So I would suggest if there is any dynamic ID generation, then I would ask them to prefer this relative element, a relative calculation. And other things are based on the application. Sometimes if an object, if it is going to be identified as an image, we have to use a different option. Like there is one tool called Sikuli. The Sikuli tool will try to automate graphical user interfaces which will use image match methods. So I’ll suggest this tool. In one of the project I tried to use Sikuli, but my client didn’t allow Sikuli, but I would suggest we can utilize many integration tools, like Sikuli, to automate to do the same things with UI automation of web and desktop applications.

Mike Hrycyk:
Cool. I rememberSikuli back in the same timeframe we’re talking about was we used Sikuli cuz it was one of the only products that could work properly with Flash. Really useful for that. All right, Jordan, do you have a trick that you would offer to our listeners?

Jordan Coughlan:
That’s the hardest question you’ve asked yet.

Mike Hrycyk:
I like to build up in difficulty.

Jordan Coughlan:
It’s sort of once you’re out of the realm of using IDs, it’s sort of an art form at that point. And the only way to get good at coming up with good locators is to practice.

Mike Hrycyk:
So actually, and, and maybe this will make you feel better. I was in my own brain. I was like, well, I’m gonna add one. I’ve come up with one. And it was almost just what you said. Which is that it’s using locators is a creative art form and you have to be creative and don’t be disheartened when all of a sudden you are having trouble finding a locator, take it on as a challenge, enjoy yourself in fixing it. And take heart in the fact that the more times you do this, the more experience you’ll have to draw on and it will get easier. And yet also give you that little spark of challenge. So, locators can be annoying, but they can also be that spark of joy that automators are getting out of automation. Would, that be a way of wording it that you could agree with Jordan?

Jordan Coughlan:
Yeah. Absolutely.

Mike Hrycyk:
Thank you. Awesome. That’s good. Well, I’d like to thank our panel Jordan and Shobana for coming today. It’s a really good discussion about a topic that is not cut and dried. It’s not black and white. It’s something that you have to approach with creativity and intelligence to make it work. So hopefully some of the things we’ve talked about will help you in your quest to be a better automator. I’d like to thank our listeners for tuning in. I think that this has been a good conversation. And if you want to participate further or ask some questions, reach out to us on one of our social channels. And, we’d like to really continue the conversation. You can add your feedback, comments, question by finding us @PQATesting on Twitter, LinkedIn and Facebook. We’re all the same in all those places. You can find links to our social media and website in the episode description. And if anyone out there wants to join in on a podcast or help us and contribute reach out as well. If you are enjoying our conversation, everything software testing, we’d love it. If you could rate and review PQA Panel talks on whatever platform you’re listening on. Thank you again for listening and we’ll talk to you again soon!