Playwright AI Vibe Testing: True Self-healing Tests with Vasusen Patil

In a land of testers far and widely journey seeking answers, seeking skills, seeking a better way O the Test Illumination Testing podcast. Guiding testers with our nation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Testicle Ovation Testing podcast.

Hey. A flaky playwright test wasting cycles. Today we're going to show you how to make them self healing with AI, what actually works in production, what breaks and how to measure the win. Today we're talking all about it with the founder of Do Not Boo, an AI QA platform that extends playwright. Really excited about this. We actually met at Test Guild IRL in Chicago and really got into AI and how it can help testers. You don't want to miss this episode. Just check it out. Hey, welcome to the Guild.

Hey, thanks, Joe. Really exciting to be here and it was really great to meet you and others at our first ever Test Guild conference in Chicago.

Absolutely. So what I thought was interesting right off the bat is I asked the question, how many people are actually using AI or ChatGPT or anything, any type of LLM with testing? And only four people raised their hands. Two of them. One was you, one was Jason Huggins, and the other two, I didn't know. So I was kind of shocked by that. What were your thoughts? I'm just curious to know because I didn't ask you what your thoughts were on that. I thought that was kind of weird.

Yeah, to be honest, I was pretty stunned by that. I looked around the room. I had assumed that about half of the people in that room would raise their hands at least. Because you even asked a simpler question. How many of you have even at least wipe coded something? And I was so surprised by that because it's so easy and free to wipe code now that it's surprising. And I realized how much of a bubble I live in in Silicon Valley.

So yeah, just curious to know then, you know, I want to get into why you found that shocking and maybe what you did to maybe help people get there. But first, maybe a little background how you got into automation.

Yeah, for sure. I've always been an engineer. I moved to Silicon Valley to join a Y Combinator startup. I was. And I wrote my first ever Automations there a long time ago. And this is when it was like RSpec and you know, selenium and you just went at it after that. I led engineering teams at multiple places and I was leading consumer engineering at Coursera.

There I never wrote automations, but my team had to write a ton of automations to keep The Coursera platform. Consistent globally.

Nice. So how then did you get into Playwright? There were so many frameworks to choose from, but we're going to get into maybe the solution you built on top of it. But first, why Playwright?

Actually, this is a good sidebar that maybe I should mention. And I told this to Jason. My biggest project. What got me my first job, I would say, was I had scraped all of Wikipedia and all of New York Times on my college MacBook with Selenium in 2010. And this was before AI, so I was always very excited about it. But as you can imagine, it needed a lot of wait statements and all sorts of drama to stop all these browsers, you know, that from detecting you as a bot. And frankly, it took like months, but it was worth it. Everybody loved the project. I got tons of great data because of it. So I've always kept in touch with all the frameworks at Coursera. We had moved to Puppeteer when Puppeteer came up, and we still had quite a bit of problems, especially because we wanted to test Edge and other devices as we were becoming more enterprise and, you know, much of the world uses Microsoft. So when Playwright came along, it was one of the few things I always keep in touch with automation. So it was one of the first things I tried and I've been pretty hooked. I also think I know some of the team members who moved from, I think, Puppeteer to Playwright here, so that there was just a nice confluence of things.

Cool. So why then we're building up on your career? What made you start think, oh, hey, I'm a startup. A startup. Not only is it going to be a startup, but it's going to be a startup around automation and Playwright.

Yeah, that's a good question. I think I've always wanted to solve real problems, and that's what I've done at all of the companies I've worked at. At Coursera's Engineering, I would say every month we had to tackle a new and hard productivity problem and everything went crazier. Once AI came on the scene, I was tasked by the CEO to basically be the AI czar internally. Just get knowledge flowing, get every team excited, get them using stuff hands on. And I was doing the same. Right. So I would say what Trigger did was just seeing how terrible the testing landscape was going to become very soon, because, you know, it doesn't take that long to realize, oh, holy shit, everyone's going to be writing a lot of code. Many of them are wipe coding. And the worst is you're and This I really truly believe. It hasn't quite panned out, but most software is going from deterministic software to partially autonomous software. And that is key currently in the world. If you ask any good testing team, they have no idea how to test partially or thought of a software. My most embarrassing moment came when my team was testing Coursera Coach, which is our chatbot. And I remember I went into one of these dog fooding meetings and I tested it. I was assured everything was great and all I said was like, hey, what other courses do you recommend, Coach? And Coach said, these are the three links for Udemy, which is our direct competitor. And I was asking the testing, like, how are we testing this? And. And their whole plan was to have an actual word they were testing in there for the competitor's name going forward so that it never responds with that. But you realize that all of this is going to get crazier once AI comes in the scene and most software starts becoming partially autonomous.

How do you test it though? That's the thing. And a lot of testers are fighting this, like you can't test something that's non deterministic. But actually that's where we're heading towards. How do you even start that or tackle that mindset?

Correct. So I have a strong belief that when software becomes partially autonomous, your test suite has to become partially autonomous as well. You cannot test partially autonomous software with deterministic tests. That's the key. So then you fight fire with fire. You add AI on this side and you start testing.

Love it. So how did you convince investors to invest in your company then? What was the pitch?

Yeah, it was actually pretty simple. Like, hey, I have been shipping software now for almost 14, 15 years. Professionally, at these companies, testing is still an unsolved problem. Yes, there are large companies everybody talks about, but if you go inside the companies, there's still a lot of manual testing, lots of dogfooding, and nobody cares about non engineering product teams, which I passionately care about. I wrote a bunch of tests even for our legal and marketing teams at Coursera. So I'm all about like, every team needs to have a high quality and deserves it from others. And then why now was simply so that was why me and why my team. But why now is simply that all software is going to get 10x crazier with much of it being written. You already see the problems. We saw this earlier. You see issues where people are posting API keys in their vibe coded app or they have security issues or just the UI doesn't Work. And the second is, as I mentioned, partially autonomous software. Every company, like literally I've looking at some restaurant websites and they're adding MCP and AI chatbots and all that. This is getting crazier. And if software becomes like that, testers become extremely important and they need tools to fight it.

I love that. So you're not saying this is replacing anyone. It's actually. It almost elevates testers to even being more needed.

Correct. I mean, what's that famous thing people say, like, in an era when like, execution is so easy? All that matters is taste. And I always say a taste and a good tester has taste. I've worked with some of the most brilliant ones in my life and they are just, they're not automation monkeys. Right. I am sorry, but like, we sometimes get confused. It's not about the automation. That's not what the job is.

100% agreement. All right, so the name of the company is Do Not Boo. I think you have an interesting reason why you call it that. Maybe we could start with that to maybe ask a little bit more what you all do and how you help Playwright.

Yeah, for sure. I mean, we are all struggling with how to call the company, to be honest. It simply stands for do not build. The company's called Donopu.

And do not build is something I used to repeat as an engineering mantra all the time to teams like don't build stuff in house. Try to buy as much as software you can. Try to partner, try to use open source libraries. Because there's a tendency in especially high quality engineering teams that they want to build a framework internally, including, you know, I've seen very good quality teams end up building frameworks and then get stuck because now they cannot use what's happening in the world out there. So that was it. The domain was available and it just easy enough for people to remember that it stands for do not build. Our logo came from a Japanese makaki. We call it our, you know, our chaos monkey that has had a little too much sake to drink. And my co founder and I, we just love Japan, so I think that's what it is. There's a lot of those.

Awesome. So what do you consider a true self healing test in Playwright?

You've had two people recently on the podcast who have really explained this and that's been the same opinion I had. One was Jason and one was Ben Fellows. What is a true self healing test? Right. A true self healing test is.

Let'S mimic the workflow of a tester. You have an end to end test. It's running, let's say it's testing onboarding. And now the marketing team or the product team added a new modal that says, hey, we are launching blah and you have to now remove that modal to continue with the onboarding test. What happens? The test fails. This is 95% of how automation breaks in production. All right? When that happens, you gotta do something about it. And mostly the test fails. The team ENG team blames the QA team, the QA team blames the marketing team. Everybody starts arguing that you should have checked this. Then you go in there, you simply add one more line to X out the model, you continue with the test, and then you re commit the code. This is not rocket science as workflow. This is something that should be part of how the test suite should take care of it. At Donoghu, what we do is when that happens, the intent of the test is actually inside the test itself. And that that's key. That's the only way this works right? Today. What ends up happening is teams just write JavaScript or typescript or Python, whatever, and then they use some random other tool to remember what this test was supposed to be doing. And then they try to reverse engineer what this test is about by that. What we do is we write the intent inside the test and then we let the test fall back to the AI to figure out, hey, is the product updated a little bit or has the test or does the. And does the test need any updating? If the test needs updates, you write the new test and let the QA engineer at that point review the code to see if this is it. So that's why I always claim, like, wake up to PRs instead of broken tests. That's something that appeals to a lot of people.

That's a good tagline. So how do you tell what, are there any classes? AI should not heal, I guess because a lot of people are like, oh, self healing is bad because it could be a real issue. Even though you explain what you know, 80, 90% of failures are due to that aren't real issues anyway.

Yeah, of course. I mean, it shouldn't do things where. And this is why you have to. This is where judgment comes in and judiciousness. How well do you write the test case really matters? And if you've seen this in your career, I'm sure it's like the best of the best. Write really good test cases. That's what they obsess about and figure out. So what should it not do if it's a true failure, it should fail. Don't try to pigeonhole and self heal things that don't need to be self healed. I'll give an example if my test said something subjective like make sure that the fall menu on Starbucks has a nice like fall theme going for it, right? If that's the case now, if suddenly there's a terms of service model coming up and you cannot access that menu, the test should self heal. But if the menu itself has become summer, the test should fail. It should not try to self heal that and say no, actually let's test for summer. Your intent was you were testing for fall.

So how do you test for that? Can you give me a demo?

Yeah, would love to.

You did mention a demo. I know people would love to see it. Folks that are listening definitely check out the link down below for the video. But we'll talk through what we're seeing as well.

Awesome, awesome. So we obsessed over how to make this super easy and we realized the best way to get started is to give people an IDE locally so they don't have to talk to their CTO or legal team. You know, not one of those cloud apps. This is fully local. None of your data is seen by us. It's all entirely your LLM models and stuff. And it's all playwright. It's just a layer on top of it. And a very gorgeous UI because we have seen that testers never get good ui. I don't know why the tools don't optimize for it. So we obsess over it. Let me start by with a template so we could just go from there. And the Starbucks one that I was just talking about, it's the easiest one to block. So let's say we are testing this, right? Go to Starbucks, assert that the featured menu page has a and let's say use the word autumn because Americans don't use that word just to show how much AI can understand, right? That's fall has a autumn season vibe to it. Do the normal test like go to this town in Vermont, ensure that this is the address that you see and you know, also look at the map. Sometimes the map based testing is very hard with canvas elements and stuff like that. These are local, whatever approved models you have. We are going to use Gemini 2.5 Flash for our browser EJ. I could also do this test manually but I'll show that later which is then just a record and play with this much. Let's just get started. So that's the intent of the test, you hit start autonomous flow. It's going to open the local browser as an authoring flow. And this is us. This is Donubu's control panel for me to take over anytime if I were a tester and wanted to just be like, no, no, no. So here you can see that there's a cookie banner that's showing up. We didn't tell our test what to do when a cookie banner shows up. Let me X out of this browser site. But like I'm expecting Tonobuz. Yeah. To agree to that cookie banner. We didn't expect that. The LLM is Gemini 2.5. It decided what to do. It figured out itself visually, where is the featured page. And now it's going to look and assert on this page. So it will try to assert like does it feel like fall or does it feel like autumn here based on what it's seeing. Right. And this is a visual assertion. Right? Not everything is visual. Ben Fellows actually towards the end of his podcast made great points about how slow, expensive and all of that it is. I think we are showing that this can be pulled months ahead of what people are thinking is the schedule. So like here you can see it's like now doing the other parts of the test. It's going to search for that town, is going to see if it can see the map. Sometimes the map is going to fail, but it should pass the assertion for the. For the address here. Oh, and by the way, why, when all of this is going on in the background here, Donubu is taking notes. So we. I'm a passionate believer that AI should not be testing your code, sorry, your product all the time. That is silly. Lots of people, when they say it's slow and expensive, they assume that we'll just have these models pointed at web pages and they're just constantly looking. It's. You don't want to add more non determinism in an already flaky test suite. We use AI mostly to author the test. That's what is doing here. It's just taking the actions, essentially what you and I would be doing if you were manually. And so like, let me give an example here. Let's go back and let's say I paused it. I just want to see where it is. Right. So it asserted that this mount is there. So let's. That's it, that's the test. While it's doing that, it's taking all these notes. So what it did with the cookie banner, what it did with the assertion for Starbucks Featured menu page. So let's see what happened to that assertion. It says it's passed. The web page explicitly says fall favorites, meet new arrivals. All right, we didn't say all of these details. We just said make sure that looks like autumn for the marketing thing. They really care for stuff like this. But what we do is then, and we don't use AI to generate code. We. This is our own engine that then takes the steps that the AI took and writes very deterministic code that you can have full control over and looks clean all the time. This is Playwright code. So this is the test. You can see that it encoded the objective as an annotation. So this is available to anytime the test fails and an AI model needs to look at it. And now these are to make it slightly less annoying to read. Let's remove. We have options on the code generation side. So let's say that element IDs are volatile. So don't take element IDs. Yeah, here. So this is. It's going to click. Agree. These are the failovers. This is what most companies call self healing, which is silly. This is just like we encode the failover once in there. So test is already way less brittle than a normal test. And this is something I've been struggling with. Like that's such an abuse term right now. Self healing, that. What do we say? Right? Should we say level 5 self healing like a Waymo, or is it a adaptive cruise control like a Hyundai? Right. Like what is it? So you can see the, the funniest part, like this is where we overload Playwright. Right page visualasert. This does not exist as a method natively. And it only comes because instead of importing tests from Playwright, you're importing it from to Notebook. That's what I meant by this is a wrapper on top. And then you could see that this is the assertion that's now been encoded as a test. We can edit all of this in a normal file and just ship it in your own GitHub repo. So that's how the test will run. Assertions for some of these and some assertions are like standard. Like, you know, look at the URL, look at the text and those. We have some other cool views for like, you know, manual testers especially who want to get into automation. We make sure that they can edit their tests and learn how to create automations this way.

So would you call this a test authoring tool powered by AI then?

Correct?

Yes, that's exactly how I will describe it.

So this is like a souped up version of Playwright Recorder. Because you could also pause what you cannot do in a Playwright recorder. And by the way, let me just show you. If I rerun this test now, it's just going to run the test really fast. I don't. Oh, I started two tests. Let's see. I've never tried that.

Can it run in parallel like that? Good to see.

Yeah, I hope so because it's all typescript.

But it's pretty funny. It just might be my computer's memory that will make it slower. But essentially right now it's not looking at, it's just running the test. It's no longer trying to figure out each step.

Unless I take over again and I say, here's the way to take over. And when I say take over like on a Playwright recorder, you don't have this concept of just in plain English explaining, actually here I also want you to do blah. And it can do that or you know, I can just take over and start clicking around and it will record my clicks and my inputs and everything, just like the Playwright recorder. So it's authoring the test with some AI magic as well.

And because automating maps is very difficult normally, like you don't know what to look for, how to navigate, knows the code to write to make it more reliable when you run it then when straight. Playwright.

Yes, that's the work that has taken the most amount of effort, I would say. There are lots of browser use agents, right. We were a little early on it, but now there's quite a few of computer use browser use. What I get annoyed by them a little bit is that they all use very expensive models and are fully visually based. What we do is we do a pretty smart mix of visual as well as looking at some HTML. You cannot look at both fully because you'll just blow budgets and tokens. We stand by it to the point where we say download the tool for free and try it yourself. Like here's for example, we looked at Gemini Flash to author that test. Let me see quickly if I can.

Yeah, I was going to ask you, why choose Gemini Flash?

Because it's my favorite, cheapest, fastest model. You can choose anything. I don't whatever is approved. Anthropic OpenAI. We support Vertex and so our monetization plays that we do this but for enterprises right now and that's where we support a lot of core of the local versions of LLMs. And what I'm most excited about is next year this will be whatever LLM model is running locally on your machine to author the test.

Oh, it'll know. Nice. So if someone wants to get started with this, then how would they. Is there a paid version? Is it free? Is it open source? What's the current model?

Yeah, happy to share. So currently you just go to Donovo.

And download it. We have it open for this month and you could just get it, download it, try it yourself. It's completely free except for whatever is your LLM cost. And if you want, you know, reach out to us, we are happy to spin up a key for people like, who really cannot find a LLM that is approved in their company or for them to use. So that's how it is currently. And then there's a NPM library package which is currently available on npm. It's source available, not yet open source, mostly because we are kind of embarrassed of how much code we have shipped without looking at it. Right. The whole plan is to make all of that as an open source layer on top of playwright. Yeah. So that's how somebody can get started with it.

Yeah.

And I can share the details of like what 160,000 input tokens on Gemini are. But my assumption, like, based on what I've done these numbers before, it's like less than 2 cents for authoring this test. Right. That's the way to do it. And then while running, it's frankly become too cheap to meter for some of the these even for visual assertions.

Cool, cool. Can you show again that the option where someone could create a test from the flow it created like it looked like you create new tests from the visual but understood it correctly. Did you have like a visual representation and then you were able to drag or you were showing something earlier?

Oh, oh, I see. Yeah. For an existing test. Yeah. So we, we had these three ways a created test is shown to a person. One is my favorite is this simple list view. Right. It just shows all the steps that were taken, what was the outcome of the step, what you know, all of that. The code view is obviously the most powerful and we expect you to download. We even give you GitHub, Actions, Runner, Playwright, configs and all of those files. So if you just download and run this package, there's even a readme involved. You can just run this locally and your boss will suddenly think you're so much more productive than before without realizing what's going on. And then there's this canvas view. It's frankly our worst view yet. But I've heard a lot of people Want it like this where, you know, they can edit stuff this way or, you know, see it this way and remove some steps.

Right? Yeah. Now I know we saw Jason show a pre preview of VIBM and he had kind of a view like this already, but it was nowhere near like this. So I don't know. This was before vibing. If everyone, by the time someone listens to this, VIBM's up. But this is pretty intuitive what you did.

Yeah, correct. I had a really great almost four hour lunch with Jason afterwards because it was so funny how we've arrived at similar ideas. Except I am all in on playwright and you know, I think that's the way to do it. I think testers love the tool, the tech and Microsoft's backing is pretty great on it. But yeah, I think, I think the future is pretty great for testing.

Absolutely. So as you work with companies or in your experience, what's the baseline flakiness rate you've seen? How does this help? Or do you have like any numbers like using this? We found that flakiness levels go down or whatever.

So what we found when new, especially newer startups who are, you know, hiring their second QA engineer, that's what I like to say. We are your second QA engineer who works with that. When that happens, we see that they're usually at like a really horrible 10% to 15% flake rate to start with because, you know, there's just so much movement in the code base and we aim to get you to under 2%. One thing we had to learn the hard way is many companies actually don't have good quality talent. And so they actually come to us to help even with the strategy of what should be our quality strategy. So we are, you know, oh, you heard it here first. We are launching an fdet, that's what I'm calling it right now, as a program modeled after Microsoft's sdet. I'm calling it Forward Deployed Engineers in Test and we are actively hiring for those so that they would be our like strategy people who we can also help companies directly. So 2% is what we aim for and I'm happy to share some examples. Let me see if I can pull them up here. So let's say this, and this is public. I'll share this in the. Oh, sorry, I'm not sharing my screen. All right, so Here's a demo GitHub repo that's on our company account available for people to see, which shows what happens when these tests are running. Some of the example Ones that we ran. So when they're running.

While we are doing this, I'm just gonna start a new run just in case so we get to see, see hopefully a live demo of it. But I have tests that are running where purposely the apps they're testing will break something or the other. They'll change the product. So the test has to look at it and update itself when that happens. Right. Let me give you an example of previous runs. Let's say it was running here. We do the reporting and entirely in GitHub. So we don't have a cloud version yet. It's entirely running inside npm, running in your own cloud environment, running locally and all the reports are on GitHub and they get piped to Slack. So we want to be where test teams already are. We don't want to have them have to learn logging into our platform and take over their test. I also hate that many companies kind of take your tests hostage by saying, yeah, they live in our version and then you can never get them without us. So we are trying not to do that.

So it's not necessarily vendor locked then if someone has an existing suite, I mean they could easily, because it's code, use it. They just miss out on other. The creation piece it looks like right now.

Correct. And if they have code and if they just want to start with one test, we say just change one test from saying test, import test from Playwright to import test from Donovo and you can just get self healing capability for that one test and see how it goes from there. So here's an example, Joe, I wrote this website, okay. It's called Unstable Survey. The reason it's called that is this is what I wipe coded every five minutes. The survey just changes forms and the test is, can you, can the survey work still? All right. We are not testing the individual form elements. You are actually testing. If the survey is working like instead of occupation, it will probably ask for educational attainment or something completely different with a different input. So this is an example where when that happened and the survey changed the test, instead of pass fail, it failed, went back to the AI, the AI redid it autonomously and said, yeah, let's update the test. Here's the self healed version of it. That's what we do for it. And then whenever that happens, we open a pull request and in that pull request you get to see the self field version of the test. So the, your team is always in charge. We don't expect AI to make these changes willingly. Some teams we have Seen are open to just saying.

Just keeping it open for auto merge. But I think, I think that's a bad idea. You should actually look at what kind of pull request then AI open. So let me see an example of something I reviewed recently regarding the unstable survey. So here you go.

There's a bug in GitHub I just realized when you click on this, doesn't take you to the test.

So here you go. So when the survey updated, like instead of asking for name, it asked for full name. Instead of asking for your occupation, the field started asking for age group. And we updated the selectors, the comments and everything because at its core we knew what the intent of the test is.

So that's an example of how flakiness work.

But how did it do that at runtime then like I understand creation, but like at runtime how did you know what backups to use that if it did change that, that would handle it. Does that make sense?

Oh, that's a good question. That is the core. That is the thing, right? I mean, it's not even that secret. I'm willing. I explained this to Jason as well on how we think we should. This should become standard, according to me. We encoded that objective in the test when it was created in English here. Right. So now I'll share a GIF with you as well. But when the test breaks, what ends up happening is in the runtime you had these modes where it was rerunning or it was figuring it out autonomously. We trigger the runtime autonomous agent to look at the browser again inside the GitHub action and re go through the test, rewrite new code and rerun it again to see if now it's working after an update. And then we diff it and send the pull request. And all of that happens inside GitHub Actions Runner. So it's not happening on our cloud. And that has been the hard part, making it that small that the whole agent can run entirely there. Oh, actually, yeah. Here you go. The survey changed as we were talking about it.

So that's an example for companies.

Okay, perfect. All right. So every time I speak to testers, even at an IRL event, they're worried about their jobs, that they're going to be replaced by all this autonomous automation. You showed the power of it right now, but you said testers are going to be even more valuable than ever. So. But we do see this morphing, especially as we head into 2026. I'm always looking for maybe trends that testers should look out for. Before it becomes critical for them to know ahead, you know. Any thoughts on that?

Yeah, I just don't believe in this, like, job loss theory. It is. It's completely backwards how people are thinking about it. And I would say it from my own experience, right when I moved to Silicon Valley, there was one weekend where we were actually moving servers from our office to another office. And as a junior engineer, it was my job to take the servers out of the rack along with my team, and we as quickly as possible moved there. And when Rackspace came out and then cloud and all of that, we were just like, that's it. So few developers are going to have jobs now. We are done. And what ended up happening, for those of you who don't know, is that there is at least 20 times more software jobs out there than there used to be at that point. And I think that's how these things work. I'll give an example of something that today is a problem. You talk to any marketing team in any of these public companies and you ask them, how much time do you do manual testing? And they say, quite a lot. It's actually a huge annoying part of their jobs. When they launch a new campaign, how many of them get a QA engineer helping them? Zero. I can tell you zero. Because they ask the cto, Many teams do. And the CTO says, I'm already underwater. My QA team is already struggling to even just keep up. So we cannot give you up. What I'm trying to say is that when the baseline of software, like what you can end up doing, changes, it's a cost problem. Today, it's not a quality problem. I actually go to any of my enterprise customers, say, you don't have a quality problem, you have a cost problem. Because for this much money, you cannot have this much done. But if for the same amount now, you can have a lot more done, what you start doing is you start fixing all your quality issues and you look at it from a lens of true quality professional, not an automator. And I think that's the difference. So if I could tell people what to do is just go back to basics, get very good at finding problems, and use. Use all the tooling you have. Don't get annoyed that there's now a typewriter and I will continue using a pen and pencil because I like that world. You know, I used to like actually making server racks happen, but I never do that anymore. Right. It's just not a. Not a world we do. And I think there's. It's pretty magical. So next time we you ask in the conference how many people have even tried AI tools like Dono Poo? Like anything else out there. Try it like try Playwright ncp Be very good at what are the limitations. You will be surprised how horrible most of it is once you try.

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

Yeah, for sure. I think, I think the best piece of advice, maybe I'm biased here is I will say go to Donoboot, download it, play with it manually. If you don't have an LLM or or use Playwright mcp if you have an LLM use that, try those things. Best way to contact me is on LinkedIn. I'm LinkedIn.in.com Vasusen it's my first name. I'm on Twitter, it's the same x.com Vasusen and I'm pretty active and responsive on all of those. Happy to help anybody with anything.

Public Stallis Awesomeness down below. Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a563 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. 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 automation testing and DevOps. If you haven't yet, join our vibrant community 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. Oh the Tescal Automation Testing Podcast 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 testers showing us secrets to behold.