AI as Your Testing Assistant with Mudit Singh

In a land of testers far and widely journey, seeking answers, seeking skills, seeking a better way o the Test Illinovation Testing Podcast Guiding testers with our nation awesomeness. From ancient realms to modern days, they lead the way. Oh, the testicle of nature Testing Podcast.

Today we're diving into the crazy world of AI driven automation assistance with Mudeet Singh from LambdaTest. In this episode we'll explore the future where natural language bridges human intent and machine execution together to help you with our testing. So mudeet unveils the concept of AI testing assistance, then interprets natural language to generate and manage test scenarios seamlessly. So we're going to discuss how this awesome tool supports popular frameworks like Selenium, Appium and Playwright and helps enable quality engineers to enhance existing code and execute tests more effectively. So get ready to learn more about innovative solutions like error classification, root cause analysis and flakiness detection that streamlines debugging and improves test reliability. So join us as we explore keen AI LambDatesk Smart AI driven test agent for high speed quality engineering teams that allows you to create, debug and evolve tests using natural language and is designed to democratize quality assurance and tackle the challenges of CI CD integrations. You want to miss this episode? Check it out. Hey, before we get into it, are you looking for a smarter way to optimize your test automation? Well, Kanai from LambdaTest might be your next must try tool. It's powered by AI. Kane revolutionizes how you approach automation testing by helping you identify bugs faster, improve test coverage and increase overall efficiency. Whether you're a developer or a tester, Kane simplifies writing and managing tests, giving you more time to focus on what matters most delivering high quality software. Take advantage of this cool innovation. Sign up now using the link down below and let me know your thoughts in the comments as well. Hey mudip, welcome back to the Guild.

Hey Joe, thanks for having me. Really great to be back over here and again chatting with you. Really great to be back here.

Yeah, I always love speaking with you. I know you did a tour of the US recently. Yeah, I guess I'm already off script, but I'm just curious to know. You speak with a lot of people. You're very personable, very knowledgeable. So is there any things you found during your little tour of maybe issues you see that people are still struggling with that you maybe caught off guard by or maybe you were validated by?

Yeah, so there's a lot of thing like it was a very eye opening tour for me so I did a tour of around 18 cities in the span of three months. I have visited Dallas, Austin, Dallas Austin, Tampa, Houston, like nearly every city in east coast, west coast, even something in between. So I did a lot of that, got a chance to interact with nearly 350 people across startups and enterprises alike. And a lot of things were pretty new for me as well. Like for example, we have been in this ecosystem of automation and testing and quality engineering a lot. But then things that I thought were the problems that were solved five years ago, six years ago, they are still a problem even for big enterprises. Big enterprises are still struggling with challenges like how to write tests. And we have always talked about automation. And yeah, automation has been around for more than a decade. A lot of people have been doing it at scale. But then what about automation of automation? What about adopting tooling around automation and CI CD? So for example, I did a survey of around 1600 companies and got to know that even though 89% of them use a CICD tooling, only 49% of those companies are using CICD to run their automation tests. Their automation tests are still clicked manually right now as well. Rates are, people have. So the problems that I thought like I've been building LambTest for seven years and I've been talking about, we have been talking about automation testing a lot and lot but then never got a chance to do a very in depth deep dive of the enterprise ecosystem as everybody likes to see here and then. And when I interacted with them I got to realize yeah, there are some problems that we thought were solved five years ago, six years ago, but they are still there either because of processes, because of there is not a buy in from leadership, there is a lot of obstacles or roadblocks in between. But then there are still problems that has to be solved. There are other way around as well. There are people who are very ahead in the game adopting AI, ML tooling and technologies in their quality engineering game. But then there are people who are lagging far behind and that's kind of motivated us to build more on the Lambda test, validated a lot of us, the product line as well that yeah are struggling with these challenges. Specifically our product lines are called Hyper Execute. That helps in the CI CD process of the quality engineering space. So validate that and at the same time help us think new solutions on what has to be built specifically to bridge that gap that we didn't thought was there. And that's how we came out with the Knight, the new NLP based test authoring platform that we recently released.

All right, so that's what I wanted to get to. I know you take a lot of feedback from your users and you build it into your product. So recently, I think it was fairly recently, maybe a month ago, could be a little more, a little less. You released something called keen AI. So I guess at a high level, what is keenAI? And then maybe we can dive into maybe pain points you heard from people and how maybe keenai can help them with those pain points that you heard about earlier when you were here in the us.

So we have been talking a lot about AI and we have incorporated AI based technologies at LambdaTest as well, specifically Lambertest product line. And we have focused very heavily on AI's feature set or AI's capability to find insights from large set of data that is do run of hundreds of thousands of automation tests. Find out things like flaky test do, error classification and all of those things. So cognitive AI or predictive AI, things we have been able to do, incorporated a lot in our Lambdas feature set that has been there for nearly two and a half years. But then we started to think about what to do, like what more features that we can build up specifically using generative AI. And then I got a chance to talk with a lot of enterprises and then we figured out yeah, test authoring. Even in the age of Selenium and Playwright and so many different tooling and so many different codeless tooling available as well, the test authoring is still a space that can be revolutionized a little bit. And that's how we came out with let's create a platform that helps and create natural language based test automation. So that's what is one of the best use cases of the AI based or generative AI based technologies. Create automation tests. Not just create, create, evolve and debug tests using natural language based processing. And that's what the KN platform is about. So the name comes from our first user. So Brad Cain has been the first user or first investor you can say of Lambda's platform and he has been around with us for now seven and a half years. And we really, really appreciate his feedback and his support on our platform so far. And we took that moniker, the name KN with the agent feed. So knai that's how the name came. But the knife capability is to recreate, debug, evolve, test using natural language based processing. And one term that in fact the Forbes team coined for us was we are kind of democratizing the way of quality assurance. So I am, is to bring more people into the quality assurance fold. And natural language based test authoring helps us do that. So people who are so even right now, it requires a lot of special skill sets to write an automation test or even using a local platform. But simple natural language based test authoring will enable a lot of other folks to get into the process. So project managers, product managers, even like the CXO level people, they can become involved in the quality assurance process, write their tests, simple natural language, and maybe evolve the tests in the natural language as well, help the quality assurance teams, development teams, engineering teams in parallel. So kind of expand the horizons of people involved in the quality assurance through right tooling.

All right, so I want to talk a little bit more about the natural language. It's a concept that's been around for a long time. Like they used to have keyword driven automation, QTP used to have dropdowns where you could select things. You had things like business process testing. Then BDD came along and people started using that kind of as a natural language. But AI, how does AI make natural language different? Because a lot of people I speak to use tools that just write the test for them in natural language and that's what's natural language plus AI. So how does AI come into play when you talk about natural language? I guess the question.

So language processing models, LLMs, they have been a game changer in this space. When we talk about low code, no code based tooling right now. So there is still a learning curve involved in that. And specifically around assertion, specifically around defining objectives, specifically on defining, like these are the high level things that I want to achieve, these are the inputs, these are the outputs. Even simpler terms, creating with these low code, no code toolings, as you mentioned, like creating using workflow based things, they. There's a little bit of friction in that. And yeah, I'll say it's a little bit simpler than writing a code based automation tool. But there is a lot of friction in that. And that is one of the reasons why they have not been able to. They have not been able to kind of do a very big revolution in the area. There is still a skill set required to do all of that, use all those tooling, which is separate from the quality engineering side of things or maybe quality standard side of things. So tooling itself become a challenge. So that is what we wanted to change. Now it's very natural to express yourself in a language in the way that we are talking right now. We are talking right now. And the way people have been using ChatGPT or tooling similar to that is the kind of things that you can see over there, Right? So you write something, you ask an agent, ask kind of, you can say a co worker, that these are the things I want to do. Our software solution should be able to do these kind of things and we should be able to get these kind of outputs. And that is pure and pure natural language. If a machine can understand that part and perform those directives, those objectives perfectly, then that's a better way to interact with the system. Right. So we have been talking about, people have been talking about API, right? Application programming interface. So it's like a human API. So converting the human language into something that machines can read.

All right, so that's an interesting point as well. You call this like an AI testing assistant?

Yeah.

Not a replacement?

Nope.

Some people actually call it a replacement. This is an assistant. So how does it assist me then? Do I talk to and say, hey, write me a script that logs into my application, adds a patient and perform surgery and then build them? Or do I have to perform those actions and it knows how to write natural language for what I just recorded?

No. So it's even simpler. For example, I can go to KN and say I want to test the logging workflow of lambda. Com. Go ahead, do that. Right, so it will directly go to lambdas.com, click on login, enter the parameters that I've entered. Maybe for example, I can write a prompt, do a login. Workflow for lamat is where username is xyz, password is abc. And based on that it will be able to perform the whole workflow. Or so we know that it's not 100% foolproof. So that's why we over that we have added features for manual interaction as well. So for example, in between you want to stop the application, do some kind of manual action to tweak it. You will be able to do that and there is another way to do everything as well. So we have created a way to do a two way sync. That means if you already have running automation scripts, you can run them at LambdaTest. We will promptify it for you. We'll create a prompt based out of those running scripts for you and then run it on kai. You can evolve those scripts using natural language and then create back a code that will append in your current existing code. So you can evolve your current testing codes using NLP based, AI based test authoring. Right. So simple human instructions will help you start your automation journey.

All right, so could you just expand on that then so it writes the natural language for you, but obviously underneath that is technical scripts, that code that actually performs that natural language. So is it Selenium, is it Playwright? And can I take that then and just run it on its own without the AI assistant?

Yeah. So we support Selenium, Appium, Playwright, so for mobile Appium and frameworks for web, Selenium, Playwright, Playwright, Cypress and like nearly 35 other frameworks in other languages as well. So JavaScript, Java, Python. So all the code, like all the prompts that I mentioned, it will create a complete test scenario, run the test scenario and you can export that in the programming language of your choice. So it's agnostic in that way. And then you can evolve that code if you want for let's say to code in a code based way. And it's other way around as well. As I mentioned, if you have already existing code, you want to evolve it, you can do that as well.

All right, so all right, about that point then say I have like a 5000 selenium test and I want to start say I want to AI enhance it. I can feed it into this tool. Will it convert it to natural language? Is that like, is that something that it would do? And then it can utilize all the AI based technology once it's in the platform.

So yeah. So in fact that is something. So Lambertes, our core expertise has been in executing the test. As you know, we have for past seven years. We have built up the framework, the processes around to execute your test at a massive scale across different browsers, operating systems, mobile devices and whatnot. So we have the infrastructure in place to execute your test and we have been providing a lot of insights over the test execution as well. So whenever you run, let's say a Selenium code base, we filter out by each Selenium command, by each Selenite command and give you the result. Screenshots, videos, logs and everything based on those commands. So what we are doing is essentially converting those Selenium run commands back into prompts that can, and then you can use that to evolve your test into more. So for example, after this login process, now let's go and do a checkout process and add in on the current code. Right. So you can involve this way or maybe you can also maintain it. So my, your test is failing because the login process has changed, the username password has changed or maybe the sign in process has changed. So you can evolve it, change the sign in username and password to ABC from ABC to def from XYZ to CVB or something. Right. So you can do something like that. So evolve the test using Natural Line. So that is something you can do.

All right, so that's another good point. So you're experts as well as running on things on multiple devices in the cloud.

Yeah.

So running a test in parallel, if someone starts off using your AI assistant, do they have to worry about creating the script in a way that it is able to be run in parallel? Because a lot of times people have dependencies like for some reason test A needs to run before test Z. Does this help at all with any of those dependencies or anything like that?

So we have a built in test manager in the place. So whenever a test has to be executed, we have. So first of all, the whole KNIFE platform is tightly integrated with our core execution platform that is hyperexecute. So any test that we create on KNIFE would automatically execute on the Hyper Execute side. So that means the infrastructure for running those tests is covered and therefore any test that you create here will automatically be migrated or run over the hyper Execute side. We have a test manager built in as well. So that will help you organize your test suits, builds and everything to kind of do a micromanagement of which test has to be done before for dependency part of things usually we are right now focusing on. So because Kenny is still in beta right now, the core features that we have right now are based on the web and mobile applications that are there online. But I think having pre dependencies injected in in that system, that is something we are working on. So we have an API based feature set in place will help you inject the dependencies in the working environment and then execute it using or create test using nlp. So but yeah, that is in place. So I think that would be there by Q1 of 2025.

Does that help with test data then as well? You can inject random test data.

Exactly. So that's the in fact the thing that we are working on right now. So for really high level enterprise complex workflows, so you can define it in your NLP based stuff, but then you would really need to at scale, you really need to inject stuff like CSVs or PDFs or some kind of data in place that is required to run test at scale. Right. So that is something we are working on. But the other way around is that if you are well versed with coding and aspects, you can write the boilerplate using NLP using Lamb test and then evolve it using your code based stuff. So best of both worlds oh, it's a good point.

It's like they're not locked and they have to use it going forward. They can use it to get started as a starting base and then if they had like an sdat, SDOT can go crazy with the code that it helped generate. Nice.

Yeah. So as I said, like, these are the core problems that we wanted to solve rather than create new ones. Right. So migration has been a big challenge. Let's say new time, a new tooling comes in place, or new technology or frameworks comes into the place. So it's. The migration has been a big problem and we do not want to create another tool from which you have to migrate to or migrate from. So there is direct options to that. And in fact, migration is one of the use cases that we plan to solve as well. So, for example, if you are using, let's say selenium 2. X or selenium 3.0, you can run it on LambTest. You will create a prompt out of it and then export it back in, let's say selenium 4. X. Right. So you have essentially migrated your code base from older version to new version or other way around. Run your Cypress code and then migrate it to like the Selenium or Playwright or vice versa. Versa, like, whatever works.

So, wow, that's a big. People ask me all the time, hey, Joe, I have all these Selenium tests, how do I migrate to Playwright? First I ask why do they want to do it? But if it's a legit use case for it, it sounds like this is almost like this will convert it right back and forth.

Yeah.

Nice.

It can help them convert it. Yes.

That's very cool.

I will not say it will do 100% conversion right now, but at least help in a lot of ways to help them do that. Yeah.

All right. So a lot of things people struggle with a lot of times is having multiple code bases. So they have to run tests, same test against web as they do on mobile. I know they're vastly different. And so maybe the answer is no and maybe it doesn't even make sense. But if I had a test suite I know runs against my web app and it's the same kind of flows, but maybe probably not the same steps. I want to run against a mobile device. Can I do that with just one script? Or is that something that's still. You're going to need to figure that out.

So I think the prompt, if it's the same, you can definitely copy, paste and run the same prompt to execute like create the same steps but copy paste the same script. Because ultimately we are prompt based authoring. Right. So you can use the same prompt for the mobile app and the same prompt for web app. For example, I have this demo of using Swiggy, which is a online food ordering app, very popular in India. So here what we do is I created a prompt that I want to order this particular dish from this particular restaurant where I am based out of this particular location. So that particular prompt I can use for web app and the same prompt I use for the mobile app. But of course the scripting is a little bit different because one is using Selenium Python and then other is using Appium. So but yeah, same prompt works. So that's something that can help up. But other way around migration, it's great to do the same thing across different browsers, resolutions, browser versions, but cross device, that would be still a challenge right now. I think that is something we can explore as a feature set.

But because you also have all these other capabilities on the back end, I could just, could I just say, hey, run this against an iPhone 15 Pro or just you know, and it automatically knows what to do exactly without configuring it.

Yeah, yeah, that works. So run it against this particular browser browser version, send it against iPhone iPhone 50 Pro running Chrome browser version or running Firefox running Safari. We can certainly do that. Yeah.

Nice. So does it also write tests for you or is that, does it take the test that you have and say hey, you have a gap. Does it know context of your application? I guess the question where it knows, maybe you're not covering this feature or maybe let me generate some tests that I know are high risk for you that coverage.

So that is something. Okay, this is a question somebody asked me just yesterday as well. Will it help me in doing so this would be problem around its code coverage. Like I've created a sign up test. Will it also do a login test as well? So not right now, but I have. This is a feature set. I marked it out yesterday itself that how we can help you evolve or extrapolate your current test cases into new test cases. So we have a, as I mentioned, we have a test case manager like a test manager. And there also we are using generative AI creating new test cases. So we can definitely help evolve your current prompts using that tooling. But to give you direct insights, for example, we are running your test these tests right now. Do you want to run these further a B test as well. So that is something we are not doing. But yeah, that's a definite good use case.

A lot of times you hear like this tool is flaky or this language is flaky, when in fact it's the way they wrote it is flaky. Like a lot of times Selenium may get a bad rap, but in fact if you look at it like this is a poorly written Selenium test. Does this have built in best practices? I guess that it knows. All right, this is a Selenium test. Let me add a weight without having this guy to have to figure out what weight mechanism to use to make it more resilient.

Yeah, so in fact that is a very important point. So flaky test, that has been my favorite topic for nearly six and a half years now. So take it. Test comes because of multiple issues. Of course one of those is there is a network issue, there is a issue with the hardware itself. And then of course system under test has changed. Nobody told you about it in the test are flaky. And then of course the test code that you have written to check the other code is that is also not worked properly. So Lambertus, our seven years of expertise has been to build the right network and right environment capabilities so that because of hardware your tests are not flaky. Right. So that is something we already had covered. Now it comes out to writing test cases that are inherently not that not flaky in nature. So one of the first approaches we went when we were building with KO for KN is that we went in a visual first mode. So that means any prompt that you write, we check it visually in this DOM that has been created whether that element is available or not. And then if that is available, we work with the visual code itself. So actually test the way a user will test. So for example, if I say login flow for Lambda test I will actually find visually the login button and click on it rather than do a let's say simple locator based stuff and in similar notes. So this is a feature that we have for our other platform that is Hyper Execute and other automation platform as well as auto healing. So auto healing using your past test data and using different locators. So you run a test at Lamberth, next time you come run the same test at us at Lambda's platform. But the locator somehow has been changed either in the code or maybe in the backend somewhere. So we'll try to run same test using different locators that we have pre stored into when last test was running. And Try to run the test using these other locators. If any test pass because of that locator, we notify that this test is failing based on current configuration. But if you use these locators, these tests will pass. Let me know if you want to run it using this locator and mark it as pass. So kind of that locator based auto healing, right? So that is also baked in. So doing a visual first approach automatically helps us cut down a lot of like in fact very huge number of leaky tests over there because now we are testing as an end user and then doing a locator based stuff because sometimes it happens is that for example an element is hidden, it's not visible. So but locator is there and it's still marking as pass even though that element is not there because it's not there in the system. So that visual first approach will tell you that even though you are asking me to click on let's say this button, but this button is not visible to the user or maybe it's out of even the screen because somehow somebody messed up the css, right? So that kind of things it becomes easier.

Nice. I love that. So I guess another thing sometimes people struggle with to say I'm a developer, I have a bug, I fixed the bug, now I need to validate the bug. And I'm like, oh gosh, where's this test live? This functional test? I don't know, I thought I said something about tagging where you can just like in maybe I'm wrong in Slack say hey Keen, run a test that touches this feature or that's functionality. Am I remembering that correctly? Is that something that this does?

So right now we have integration with jia, so we are working on things like Slack, Microsoft Teams and other communication based tooling integrations. So what that means is you can write a prompt directly from Slack and run it at kn. So in fact this is something that would be live this year itself. And yeah, that's the use case that definitely somebody can do that or other way around that already have a PRD or a ticket built in. In jira I can click on a button over there. So I have fixed that issue. I want to run it and validate it. So I can go to my JIRA ticket, which obviously every developer has opened up in a separate screen, right? So I open it by my JIRA ticket, click on a button and it will read the requirement steps or the whatever PRD is there in the ticket and run those steps back at kni. So With a click they will be able to run those steps directly at laminate Kni back.

Nice. And I love the idea that maybe I get a user reporting an issue to me.

Yeah.

And they say they have an iPhone 12 or something. I'm like, oh, I don't know, can I duplicate it? Replicate it with your platform because it integrates with your backend. It's as easy as me just saying run this test against whatever Android with this flavor and it will. And you could see with the videos and everything now. Okay, I see now what they're seeing. Is that true.

So if you have a detailed user step that these are the actions user has performed and if you want to run it back on our platform on a specific use case, on a specific device configuration, you can definitely do that.

Yeah, very cool. I also saw something about a two way editor that makes maintenance easier. Is that something you could talk a little bit more about?

So in fact that is the same thing that I was talking about that gotcha. You have two way sync between your code that you already have present and you want to evolve it using Knight that you can do so. And the other way around that is you already have a prompt based knife test and you can export it as a code format.

Love it. All right, so I know you said a lot of times you spoke to people they didn't have automated tests integrated with their CICD systems. Does this help at all with that?

So right now we are working on that direct integration. But our platform that we had, the Hyper Execute, that is something we innovated before Knight. So we have the CICD features built in, baked in in the Hyper Execute platform. So Hyper Execute has this cool YAML based CI that can help you create or orchestrate your tests that you have already built in. So a lot of orchestration, a lot of you can say karate or ninjutsu required to orchestrate and scale up those tests so that things Hyper Execute already tackles in. So things like auto retries, load balancing. So distributing your hundreds of tests across the let's say 50 machines that you have in the most efficient manner so that test have the least test execution time. Things like do a fail first mechanism. So for example you run 100 tests last time out of those 20 were failing. So next time you run the test, the failing test will execute first. That will give your developers the fastest feedback. Whatever you have built and did changes in the system. These 20 tests will validate that which were breaking earlier. They will now execute first and give you a feedback that yeah, everything is working and rest 80 will continue to execute to build up confidence. Right. So those kind of feature sets we already have big then in our Hyper Execute platform. And there's of course knives, definitely as it is running on the Hyper Execute, we will have those same feature sets available with Knock.

So I want to get into. I know another thing a lot of people struggle with is debugging. So they come in, they run the test overnight, still they come in, they have a hundred failures and they go try to debug them. And by the time they're done debugging, someone's already kicked off the next build and it's like, I can't keep up. So is there any AI powered debugging features that help them triage really quickly to know? All right, yeah, we have a hundred failures, but fix this one thing, you fix 99 of them or something like that.

Yeah. So that's in fact another feature set. So as I was talking about earlier, right. That we were talking about, what are the core features for AI that we can incorporate in? Lambata is the first thing that we came out with related to cognitive AI features. And that means look at hundreds of thousands of tests and see what insights can be found over there. And one of those insights was error classification. So let's say you have thousand tests. Out of Those thousand tests, 200 were breaking. But because we have access to all the test executed, all the test execution data, we can look at that data and give you patterns. So for example, 200 tests are failing, but out of those, 150 are failing because of one issue. For example, your login button has failed or your login workflow is breaking. So we'll give you a classification of those errors that you don't have to debug all 150 tests. Just this one issue. Just debug it and run it again and see if it works out and then maybe you can spend your time in debugging rest of the 50 issues. And even in those 50, usually these are classified into few sets. Another aspect we are able to highlight our flaky test that these tests were passing earlier or failing earlier and now these are giving different results based on your test patterns. You are able to highlight that nothing has been changed yet these tests are failing or these tests are passing. So something this is, there is a flakiness in this test that you can look into. So help them do a classification or error classification, help them do a flaky test analysis. Another aspect that we are really proud of is in fact that was Our first gen AI feature was give them a root cause analysis or an error remediation. So because we have a billion tests that have been executed our platform, all the error codes and why that error code came, we have an understanding of that. So we are able to give them in the insights that these tests are failing because of this particular issue. Maybe you can go ahead and check these areas in your code and see if that can be fixed. So kind of give them a RCA with a single click on why these tests are flaring and possible ways to remediate that. And I think this would be our another target of knife is that we can do a pull request back in the system and fix that test for them. But that is something we are still working on.

That is cool.

Yeah.

And I think the last piece is a lot of times when I was working back in the day, I had to do an Excel sheet and report every run why it failed and then do a trend to my management every month or every two months. If I'm an executive and I have 12 verticals, they're all running tests and I just need to know, okay, how are we with our testing? It seems like because you have all this data, does it give you like almost like a 360report that they can look at and at a high level say all right, here's where we are, high level. Maybe if I need a dive, dive down I can have high level KPIs or something that lets them know why things are failing. I don't know if that makes sense where they are.

Yeah, so that's in fact another tech stack. So we have been talking about stacks of system, right? So we have a test execution layer in place. Over the top we have added orchestration and auto healing features. And then over the top because we have all this test execution data is reporting. So creating reports, creating dashboards. In fact, I'll say it's a little bit easier because we have all this data you are able to do. But the things that is really over the top is just intelligence. So observability is one of the things, analytics is one of the things. You should be able to see where the health of your applications is. But the truly best part about AI is finding out insights from that test execution data, for example, give you direct insight that your tests are like 90% of the tests are passing, but these tests, 10% are failing. All of these tests were run on Safari. So your application is not working on Safari because out of those hundreds of thousands of tests you have written just 20 tests for Safari or maybe repeated those 20 tests across 500 different configurations. Only Safari ones are failing for example. So give you those kinds of insight. It is breaking on Windows 11, it is breaking on Safari or it is breaking on. Or these particular. Again the point here is I have hundreds of thousands of tests finding out insights from there. And even when we do a predictive analysis that these tests are failing, if the trends continue, your next test of those will be failed as well because nothing has been made to improve that. Right. So that is pure and pure test intelligence. So that is also what we have built up.

Nice. So is there anything else about K that you think folks should know more about that maybe a feature or function that we didn't cover?

I think we have covered most of the things. So two way integration, that is there are the integration syncs that we are building up. It's available for both web and mobile and covers a lot of browsers devices. All that is available at Lambert is that is there. We are in early beta right now. That means very select few companies are using and select few users are using the platform and we are rolling out access to more users even as we speak right now. And there is still a lot of feature sets that we have to build up. But overall I feel that we are in a very light direction. Specifically the problem statements that I got back from big enterprises in my last three months and solving those challenges right now with a tooling like kni. So I'm really, really excited about this new roadmap and capabilities that we are building and also looking forward to the new feature sets that I can build over the top for this based on customer feedback.

Could anyone sign up for the private beta or is it certain criteria they need to fall into?

No. So right now we have opened up to very diverse groups. So it's. You can go ahead and sign up and we'll be happy to open up access for you and but it's usually based upon the infrastructure we have available to execute this test. So as we are scaled that infrastructure up and we are doing it progressively, we are opening up access to more and more people. We have already given access to I think within a thousand users who are using the platform right now and are scaling that up as we speak.

Awesome. We'll have a link for that down below, so definitely check it out. Okay Munit, before we go, is there one piece of actual advice you can give to someone to help them with their AI automation testing efforts and what's the best way to find or contact you.

So the one advice is so as in fact that is something we were discussing earlier as well is that the world is changing a little bit and the way we write run test, in fact the way we do quality engineering is also changing a little bit. It's great to read more about it, understand this technology, more about it. It's not a thing to panic about right now, of course, but it's always good to be a step ahead in the new technology game. So do a deep dive into this concept that will make you a better quality engineer and better tester. So that's my core advice. And yeah, feel free to sign up for the beta platform and be happy to have on the platform.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a520 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. 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. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of the automation testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

With lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.