Transforming the Way You Test Your ERP w/Pankaj Goel

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Pancadge all about how to transform the way you test your ERP and and a lot more around automation. If you don't know, Pancaj is the Opkey Co founder, Chief Executive Officer and Executive Chairman of the Board. He founded Opkey in 2016 and it really is a model how to create an organization or a software that actually delivers on certain automation values and problems that you're probably dealing with, especially around erp. So really excited to talk to him because he actually has hands on experience as being a test automation engineer doing multiple things for companies like Oracle, HCL Technologies, Adobe Systems. So not only is he a founder, but he also is sounds like someone that actually knows automation. So really excited to talk to him on this episode. You don't want to miss it. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment. For Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive Sponsors section to try it for free today. Check it out.

Hey Picach, welcome to the Guild.

Thank you so very much Joe. It's a pleasure to be here and thanks for having me on the podcast.

Great, great. So before we get into it, is anything I missed in your bio that you want the Guild to know more about?

No, I think that's pretty much it.

Cool, cool. So as I mentioned, I believe you started your career actually as a tester. Am I correct? And if so, like, how did you get started in testing?

It's an interesting story, man. I started my career with Mercury interactive back in 2002. So I graduated from IIT and those were the infancy days of test automation. I was one of the few certified guys in India on Windrunner and QTP 6.5 back then and that got me initiated into this world and I have been hooked on since then. So I worked with Mercury directly, worked very closely with folks in Israel for the entire development and testing and you know, since then I've been into this domain working with some of the largest test automation programs across the globe. I've had my fair share of success and failures man.

So let's talk about maybe some of those failures that maybe wanted you to find a company that actually is around automation testing. So as a tester, what were you seeing? That maybe you thought, you know, Mercury is good, but I find that, you know, X, Y and Z really could be addressed better. Anything like that that you saw as you were a tester that made you think, I think I could maybe create a solution that can help in these areas that I know all the testers are dealing with.

Sure, absolutely. So you know what I realized over a period of last 20 years, and it's going to be 20 years this year since I graduated and came into test automation.

Congrats. Nice. Nice.

Yeah. So you know, one thing that I realized is that there is a big chasm that exists between technical and the non technical users when it comes to test automation. So if you look at the generic applications, which are more like web, mobile or I would say the custom application side of our enterprise, there are tons of tools out there, right? Winrar was great, QDP was great, which is now uft. And then once Selenium came in, everything moved to Selenium. Now Cypress, a lot of tools over there. But when it comes to the enterprise side of it, that's where every tool, every platform suffered. Winra was good, QTP was good at handling certain things, but it was not enough to handle all the complexities of ERP testing or ERP transformation. And by erps I'm talking all about the business applications. You know, the traditional Siebels and PeopleSoft and now Oracle and you know, and Salesforce and SAP's of the world. So most of my failures actually had to do with the fact that the tools were not a good fit for any ERP specific test automation program. Good in the beginning, but the maintenance and stuff like that, as the changes come in, I mean that was a big, big pain area. And that sort of prompted us to, you know, just see a tool that we would want to use to create a tool that we would want to use. And that's Opkey.

Great. So why ERP though? Do you see a lot of companies that actually use erp? Because a lot of times when I speak to testers, it's I guess it depends on if they're an enterprise or not. A lot of them don't know that they may have an ERP application or like how big of a demand is it for ERP testing?

Again, a great question, Joe. You know, if you look at budget that a typical enterprise spend, right, they spend money on their custom applications. Obviously the customer facing applications, you know, all Those omnichannel experiences and stuff like that and then they spend money on these enterprise applications. A good example is transforming their financial systems from Oracle EBS to Oracle Cloud. And you will be surprised to know that 70% of typical IT and business budgets, they go into this backend ERP transformations, which means companies spending more money, more time and more effort into these backend transformations. And the reason is simple, right? Without transforming your supply chain you cannot have a seamless user experience. It's as simple as that. So those are the ERP areas. There are a lot of initiatives going on over there as we speak and next eight years are going to be very critical for this industry as the digital transformation takes shape.

Why is that do you think? More companies are going to be investing in no code solutions and that's the wave of the future, package based applications?

Yeah, I think more so past couple of years with all that's happening in the world that we know about it has made companies realize that they need to be more nimble and agile in their business processes, the way they respond to the changes. Right. And that has led them to think about transforming their ERPs, the backend ERP, their financial systems, their supply chain systems, their human experience management system. So those migrations as you speak are underway. A simple example is migration to cloud. So if you look at it at this point of time, only 9% of enterprises have moved their ERP to cloud, which means that there are still 91% out there which are going to make this transition over the next seven, eight years. And I mean that's a big, big pain area in the market. Companies are not ready for that.

Yeah, absolutely. I mean cloud native I think is going to be the way of the future for sure. You did mention something about supply chain. I know this might be off base in the news. There's a lot of things about security and supply chain does this having to do anything to do with erp. And when someone's testing erp, is security ever part of that, that test plan?

I mean security is definitely a part of the test plan. More around the segregation of duties and the related testing. But the testing that we are talking about here is a larger picture. It's like end to end testing, right? It's about how your order to cash workflow happens in a company, what customizations you have done, what configurations you have done and is it working fine. Typical example to think of it would be CRM. I was working with one of the largest education provider in the world and they had this Microsoft Dynamics CRM and they say that every hour of downtime cost them $100,000. So it's that kind of impact that these applications and their uptime can have.

So I've worked for a lot of enterprises and they have organizations all over the place. So I guess I don't know how much exposure everyone has their applications that are being developed using erp. So is this part of a normal developer life cycle or is it because it's a no code solution, you have business users doing it and maybe your developers and testers aren't even aware of it. Like how do ERP systems that are developed actually fit into the software development lifecycle of a normal enterprise company? As a part of custom development, As a completely different group within the organization?

Yeah, so think of it as a completely different group, Joe. Most of the companies, at least the medium to large enterprises, they don't make their own custom erp. If they have to use a supply chain, they would use perhaps a SAP or they would use something like Oracle Supply Chain Management or more specialized software around it. So there are specialized packages out there which enable enterprise to implement these supply chain life cycles pretty seamlessly and those are the ones that we are talking about. So there is not as such big development involved, but IDEA is retrofitting. So they have their legacy software which now needs to be moved into this Oracle space or SAP space. Right. So most of the business groups, they get the budget and then it has to work with that budget to make that transition happen.

So I assume that that's where the issue comes in. A lot of people might say well I'm using a packaged application. Don't they test their, their application? But I guess the different configurations and from what I hear a lot of times they release on different cycles. I may throw something off. Are those the type of issues that someone will should be aware of as if they need a test in the RP type solution?

Absolutely. So three key issues over there Joe, that we see and that people struggle with. One obviously is the platform update. So if you look at Oracle World, right. Let's compare Oracle EBS to Oracle Fusion Cloud today, which is the cloud version of their erp. EBS used to give an update once every year. Right. And Enterprises, since it was on prem, Enterprises had an option to test it the way they want to test. I mean if they want to put update now, great. Otherwise they can defer it by one year or so. Cloud it doesn't give them that luxury. Which means that every quarter they are going to get an update every Quarter they are going to test their business processes. So the testing effort has gone 4x or 5x compared to the on prem stuff. So platform update definitely is a big driver. Other thing obviously is the configurations. Everyone wants to bring about the changes faster. Right. So as they are configuring, they want to make sure that their business processes are working fine. The user experience is seamless. The end users who are going to use this supply chain software and there is no downtime. So a lot of companies have started adopting agilent DevOps. By the way, it's still a early day as to say how to do agilent DevOps in ERP, but we are working with a lot of enterprise in that direction.

Great. So how much does the performance come into play? Once again, I worked for a large company, they had like a green screen application and people really had to fly through it because it was all keyboard. Then they ported over to a browser and people wouldn't use the browser because it was slower. So you mentioned a lot of people taking legacy applications and porting them over to erp. Are those the type of. Is that another thing that people maybe need to be aware of as well?

Typically no. You know, because that's the whole idea of moving to cloud. You don't have to worry about, you know, your performances and your maintaining your servers and stuff like that. So for a legacy application where you were hosting it within your own premise. Yes, because it's your own servers and performance testing is important. But now as you move to cloud, at least that's one aspect that you cannot be worried about because the Oracles or the saps of the world, they take care of it. You tell them that I want 100 users provisioned and they set up enough capacity. Obviously there are some challenges in terms of integration, but that's a limited aspect of it. It has largely to do with functional testing and functional implementation.

So when we're talking about functional automation, you mentioned Selenium. Selenium is great. It's for web browsers. What I loved about Windrunner and Enterprise is you had all these add ins so you could test the web browser, you could test an Oracle form or whatever, you could do a whole workflow. Is that with this type of solution is you can use Selenium, I think for most ERP testing. Is that correct?

Yes and no. I mean if you look at it that way, Selenium is obviously it works with any web based application. The problem with Selenium or Cypress or any of those tools is that they are not built to handle the complexity of a metadata driven application. So most of these ERP applications, take Oracle Cloud for example. Right. A simple thing is with every refresh they change their control IDs. There are no identifier based on which you can uniquely identify that specific control on the application. Complex tables, complex iframes and stuff like that. So we have seen a lot of enterprises who started working with Selenium on Oracle Cloud or Workday or SAP Fiori interfaces and then they had to junk it after two years because it was simply not maintainable. So cloud ERP require a different kind of tool that the likes of us and they are limited players in the market. Right. We and some of our peers we are providing where we understand the metadata that is used to generate the UI and work with that. So it's much more involved than Selenium.

Gotcha. Also I know a lot of companies I've been speaking with are all say no code, they're all no code and they all deal with package based applications. I guess a lot of them have partnerships with the company so that when they do release the software is already in sync with them. Is that something that AppQ offers as well?

Yes, it does. But let me take you back to this entire no code approach, right? I mean I'll tell you how we are reimagining the entire no code space and making it truly autonomous. So when some of the other players in the market talk about no code, they rely on the business users knowledge to drag and drop and you know, and all those keywords and stuff like that that we all know in test automation space. What we have done is we have reimagined the entire test automation assets for ERP application. We start with the concept of discovery where we it's a patented algorithm that we use. We call it test mining where we point OPKEY to your environment or ERP application. We mine your traditional logs that your business users have been doing and then we look at your configurations, right. And then upkey models the right test cases that you should be testing. So I mean if you look at it from the step one, the test creation process in itself is automated for you. Right. It cannot get any better than that. You have the entire suite of test case which gives you right coverage. And if you look at it Joe, if you look back, traditionally that has been a problem. Because if I am a company, I have implemented Oracle, how do I know that what I'm testing? There are no code coverage tools in ERP world, right. We don't know whether we are doing the right coverage or not, it's all guesswork. We have taken that guesswork out of the equation right now. So it's just essentially three things, right? We do the discovery test, discovery autonomously and then we have this. One of the unique advantages that we have, which has been recognized by a lot of our customers and some competitors as well, is our accelerator library. What we have done is we say that hey, we understand ERP maybe sometimes better than the customers, at the risk of sounding boisterous. So we know how the components are supposed to be designed. So we'll give you out of box library of components of business processes that can then be adapted to your workflow. So effectively 90% of your heavy lifting is done for you on day one. Implement automation for Oracle or SAP or Salesforce. That's true. No code, right? That's what I call no code. And then whatever is remaining 10% that you can actually use our recorder interface, drag and drop interface and stuff. But that also makes the entire onboarding really smooth. If you look at Selenium or any other tool out there, it takes three to four months for a company to onboard a test automation program for ERP for us, two weeks and done.

Great. I thought you said there were three. So you said Discovery Accelerator, what's the third piece?

And the third one is maintenance. And that's where most of the automation programs, they fail. So I mean if you look at it, the changes are coming, right? And that's where if you start automation with Selenium, great in the beginning, but it becomes impossible to maintain because there are changes coming in your control IDs and you need to go and update your page object models and what all and whatnot. And Selenium is not equipped to handle that. That's where we, what we have done is we have taken a different route. We do a impact analysis. So we have this autonomous engine that runs on impact analysis that understands what kind of changes have happened across two releases, be it platform release or the configurations you have brought. And we do a self healing of the script, a true self healing based on our AI models that tells you how exactly these scripts can be made error free for it to run. And this is a self learning algorithm. We are utilizing the power of crowd. We have more than 250 customers. So each of the failures that we get from the customers anonymously is made to make this self learning algorithm better.

Very cool. So let's break each one down, I guess. First one's discovery. And so in discovery sounds really cool. So it sounds like you almost have a sniffer in production where it goes through the logs. And so the test you create would be more realistic also as well, I would think. And so you wouldn't waste time testing maybe features that 90% of your customers probably don't even touch or aren't even risky. Does that help, I guess, lower the amount of tests you actually have to create and make more effective tests?

Absolutely. Bang on. What we are using is we are using technology called process mining at the backend, which so far has been used by companies like Sylonis and all for business process optimization. We have taken the same set of technology, we have added our own twist and we are utilizing it for test. That's why we call it test mining, Joe. And the purpose, exactly as you said, is to identify different customizations that people have brought in, what workflows they use and prioritize testing for you. Right. And then we add one more twist to it though, which is your configuration mining. And that's something that only we at Opkey are doing because ERP is a game of configurations, right? Particularly in Cloud. So API automatically mines your configurations, it understands how many business units you have, how many shipping centers you have, and then it puts that on top of your mind scenarios to tell you how many test cases you should be testing. Are you testing more, are you testing less? That's the final output.

Huh. So does that help you create environments then for testing to make sure it's exactly like production before you actually go into production, rather than oh, we didn't realize that configuration was set and our staging wasn't set like it is in production or something like that.

Yeah, not the original intent of that, but many of the Companies are using OPKeys process mining to actually do that. People are also using it to compare snapshots, the configuration snapshots across different environments and making sure what change across environment. So there are so many side uses that we didn't envisage when we started. But companies, our customers are finding innovative use for this technology.

So are most ERP things backend systems or are they customer facing? Because I was thinking if you had like 20 customers using an ERP solution that you have, that config would come in handy too. If one person's having an issue and you can look at the config and say, oh, how easy does it know? Like this is what's different between this and your 10 other environments that are working fine, they have this configuration set, this setting set, that shouldn't be set to help you troubleshoot in production. Almost.

Yeah. I mean you got it right. So this is exactly how it happens. So Oracle has 12,000 customers on their Oracle cloud right now. If we are working with a customer X customer, right, and they have a problem with their configuration, the engine automatically can alert all the other users using the similar configuration that hey, there are changes over here that coming that's going to impact your business, users and testing. And that's the true power of crowdsourcing and making sure that the platform core algorithm is ML driven.

Nice. So I guess another thing that would be helpful then. If you have 100 tests, the ERP makes a change that's going to affect a component. It would I guess tell you which hundred of tests may consume that component quickly without you having to go and manually verify. Okay, this test uses it, I need update or it automatically does it for you or anything like that.

Exactly. I wish I could show you the UI over here, the user interface, but.

It'S exactly like that, right? It shows you which activity in your entire ERP chain it got impacted and then it tells you what all test cases which are consuming this component are impacted because of it. So you are in control of the changes that are happening to your application because of changes that these ERP companies have brought in or the changes your configuration, business configurations have brought in. You are totally in control of that and you test exactly based on the risks highlighted by those changes.

Cool. So I'm digging the discovery piece. The second piece is accelerator. So I guess there must be canned tests that every organization has to run when they're using an ERP system. I assume the accelerator would have like a starter pack maybe of tests that people could get started with. I'm just making assumptions here. Haven't even seen your solution ever. So is that true or no?

That's absolutely true. That's absolutely true. But the only thing is, our starter pack is more evolved, Joe. Because what we have done is since we have been working on it for past three, four years now, we have evolved it into the test cases which are more aligned to a specific industry. So for example, manufacturing in a pharma and manufacturing in an auto industry have to have different processes right now, same set of canned test cases won't work across both. That's the flavor you would need in terms of the ERP applications because the manufacturing processes are different. Right. So our test cases are much more evolved, much more comprehensive. And the second piece is because we are discovering the configurations, the configurations can automatically be applied to these accelerators. The test cases that we have pre built test cases, which means on day one, when you deploy, 70% of test cases are customized for your needs, which is not possible with any other starter pack, the vanilla pack as we call.

It, because it's doing modeling. So it knows automatically what is different in your system and it can update it automatically.

Absolutely. And it can bring in your configurations as test data within the system. A simple example is approval workflow. Think of it this way, right? I as a company can have three different approval workflows, whereas you as a company, you only need one approval workflow. For anything above $100,000. You obviously have a lot of money, Joe, right? So you don't want anyone to be bothered about it.

Right? That's where those configurations can change your automation. And for us, that's automatically configured based on what we read from your configurations.

Nice, nice. Okay, and the third piece you said was maintenance. Now maintenance, like you said, is definitely a killer of a lot of teams that, you know, they have a thousand tests. Even if 10% of them fail, it takes a long time for someone to go through them before another test kicks off and they haven't even had time to fix what the heck happened. How does it help with maintenance? Again, it automatically is able to tell you that maybe this one component affects all 100 tests. So rather than having to look at each hundred tests individually, fix this one component, that one component, it would resolve all 100 issues that you have.

Absolutely. So what happens, Joe, is that the first piece is change identification, right? So our impact analysis engine is a real time engine that identifies changes happening in your dev environments, right. Or staging environments across. And you know, you can compare those environments and see what changes are coming. Once you have that, then our algorithms, since we have the artifacts within Opkey, we know how those changes are mapped to the components and what are the potential impact it can have on business processes. So we highlight exactly those components and business processes for you. And once that is done, I think the last piece is if as a user you feel that, yeah, these are valid changes and these need to be incorporated in your script. All you need to do is click on a self heal button and then the entire script is regenerated at the backend based on those specific changes that are coming in. So now one beautiful aspect of this is you don't need any technical expertise to go and look at your page object models or go and change your script or do Java or even drag and drop these different components. Right? Even in a no code solution for a business user, most of these changes are incorporated out of the box as soon as they do self healing.

So I think this would freak out a lot of testers because they don't seem to like black box type of solutions like this. But it seems like the user of this type of solution would find a lot of value from it. They would never think about, oh, I want to look at the code to see what it's doing because there's no need to. It almost sounds like, yeah, absolutely.

See, I would be lying if I say that we are doing it right 100% of the time. It's a AI algorithm. Right. It's reaching there, I would say. But testers don't have a reason to be freaked out because what we do is we give you total control on the changes that you are bringing in. I mean you have an option to say do these changes in bulk if you trust Opkey enough and you should because we have the power of 250 enterprises that's powering this platform. Right. But if you don't want it, you can go and review each and every change and say fix this or don't fix this and then review the code as well as to what code at the back end got fixed. And if you want tinker around with it, you have the full flexibility to go as deep as you want. So as a technology platform, Joe, we are agnostic. I mean we support all technologies. Your green screen applications, you mentioned, your web applications, your Java applications. So you can go as deep as you want.

Yeah, so that was my next question. Is this only for ERP solutions? I know a lot of times sometimes people get fixated on I need one tool for all my automation needs and sometimes they shoot themselves in the footwear. All right, someone uses Cypress, that's fine for the type of testing they're doing, someone uses Selenium, fine. But for erp, we're going to use this solution. Do you see that? Or do you normally see this solution can handle all three of those scenarios that maybe a developer, a tester and a business user would be concerned about?

Yeah, I think what we are seeing more is a single platform across all the business application needs. And that trend is definitely catching on, Joe, because if you look at it, the ERPs don't operate in a standalone world. Right. You would have a Oracle Financials being tied to a Salesforce cpq. So end to end business process would have to test both Salesforce and Oracle or it can be a custom application built in house on desktop applications. So I mean I would say Test automation doesn't exist in Silo and any platform has to support, you know, end to end ecosystem or end to end business processes across multiple technology. And that's what opkey is. And that's one of the beef I see a lot of business enterprises having with, you know, with one application specific tool. Now you might have a Salesforce specific tool or you might have a SAP specific tool. Great for a program but not good in long term. And that's what organizations are getting away with.

Gotcha. All right, so you are a tester by nature. You started off as an automation engineer with WinRunner. A lot of people would say that record and playback was over promised, so now you have a no code solution using AI. And so it almost sounds too good to be true. So what makes it different now in 2022 than when it was when we started in 2000 that makes these type of solutions viable? I think they work more than maybe they may have been advertised back in the day. Does that make sense?

It makes perfect sense. The comment that I'm going to give now, Joe, is going to draw a lot of ire for you. So okay, please be ready for some brick bats. I personally believe being part of that windrunner developer ecosystem back then, working directly with Mercury Record and Playback was the most beautiful technology ever designed. Right? And I have seen a lot of people talking about why it's not good. I think the reason is the way you are using it, the way you are using it to just do everything that you know that is entailed in test automation. One reason why Record and Playback was, as you rightly said, over promised in that ecosystem or most till most recently, was that the technology didn't exist to handle those dynamic objects or dynamic controls with AI. Now we have power to, you know, to handle those dynamic controls, to handle the changes. Which means your script, even a record playback script, is not brittle as it used to be in the past, right? The record playback options that we have today, just like you have in OPKey, are much more flexible and they understand the application better than the tools of the past. I'll give you example, Joe. When we work with Salesforce, you know, we just don't rely on UI controls. What we do is we go a level deep, we go to Salesforce, hit the APIs, get the metadata and correlate the controls on the screen with that metadata. Now that simple hack and it's a truly legal hack, so to say. But that simple thing makes it at least 90% more reliable than selenium or cipros. Or any other tool for Salesforce.

You just jogged my memory about a question I wanted to ask and that is, are all these UI tests or are they API tests? I know a lot of times someone was telling me about Salesforce, they were doing performance testing, it was really difficult, but they didn't know there was an API layer that they could tap into to make it quicker. Is that something that this tool can say, hey, there's an API for this, let's do it at an API level versus a longer front end type approach?

Absolutely, absolutely. As a platform, we support both the API test and the UI test. Right. Particularly in the case of Salesforce, we have a feature where if you are testing a feature, the API test would be created simultaneously with the UI test without you even knowing about it. Because we know the APIs that are hit at the back end from metadata, which means that you can combine both UI and API tests together in a single script and then use API test for performance testing, as you rightly said. But mind you, not every platform has that evolved API interface like Salesforce. There are still platforms which are making that journey as we speak, like Oracle. They have come a good long way from where it was about two years back. Oracle Cloud. Yeah. But the API ecosystem has to evolve over there.

Cool. So does APKEY have any case studies, something that you know before your solution and after that can get people to say, okay, it's not just smoke and mirrors, it's been in, you've been around for four years, it sounds like you had a bunch of customers. Any case studies around this also?

Yeah, I mean, Joe, I mean if you look at it, we have been fortunate to partner with some of the largest enterprises out there. So if you, I mean, if you look at our customer list, we have 20 of the Fortune 100 enterprises that are working with us to, you know, to transform their ERP through SI partners, through, you know, direct selling. And one case study that I, that I would like to mention over here is, you know, one of the largest apparel manufacturer and retailer here in us. They have six different brands and they were moving and consolidating their entire ERP to Oracle Cloud. So that migration is underway as we speak. And you know, they are very close to production. So far Opti has helped them save about 900k in terms of their testing budget by shifting testing left in their ERP migration cycle. And it's a recognized case study on our website, codes and stuff like that. So that's the kind of savings. One more thing I would like to mention here, Joe, is that if you look at opkey, we are working with some of the highest regulated industries out there. So seven of the top 10 pharma companies of the world are our customers, you know, for solutions like Trackwise and viva, which again are enterprise packaged applications. We are technology partners to VIVA as well. The only testing technology partner to viva.

Nice. So that was, I guess a question I was thinking about as well. I used to work in regulatory environments, FDA and sometimes even using an open source tool, it's like, well, you need to validate it. So I assume your solution is because it's already validated. Just go to your compliance and say, look, here's their ISO, blah, blah, blah, whatever.

Absolutely. That's typically the validation in that space is GXP compliance. We are the only platform that's validated that's GXP compliant. And in fact, I mean, that's the reason why people would work with us. The pharma companies can work with us. And that's the reason why these 7 of the top 10 companies are choosing OPKI. We take a lot of pride in our security and privacy policies. We have all those compliances with us. We are HIPAA compliant, you know, we are SOC 2 compliant, we are GXP compliant. So yeah, so that makes us a perfect fit for this validation work.

Cool. Okay, Pankit, before we go, is there one piece of actual advice you can give to someone to help them with their ERP automation testing efforts? And what's the best way to find, contact you or learn more about opkey?

All right, absolutely. Joe, let me start by saying that it's great to be here on this podcast and I have been a big fan of your work, man. I've been following your podcast and your articles over the last couple of years and off late this has become my go to place for the testing news, or at least the more authentic testing news, so to say. So you're doing a great service to the community. Please keep it going. The best way to find opkey is opkey.com you know, you can just go to the website, you can have a look around. You obviously can, you know, reach out to the folks that I mentioned over there. I'm available on LinkedIn. One piece of advice that I would like to give Joe is test automation is past test automation and what we are doing today, it's radically different. Right. So if you are undergoing a ERP migration in next couple of years, or as we speak, or ERP transformation program, think about test automation not just as your time saving or money saving, but as something that can really help you transform your ERP experience for your end users.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a395 and while you're there, make sure to click on the Try for Free Today link under the Exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.