Exploring Playwright and MCP with Debbie O'Brien

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

Hey, do you want to learn all about the latest and greatest with Playwright and mcp? If so, you're in for a treat because we have Debbie o' Brien joining us. She's a massive expert in this area. She's the principal Technical program manager at Microsoft, which is part of the developer division team advocating for Playwright end to end testing. You've probably seen her all over the place. She talks at all the things about playwright. She gives a lot of talks on testing. She's building the playwright community. I think she's running the Ambassadors program and a bunch of other stuff. Really excited to have her on the show. You don't want to miss it. Check it out. Hey Debbie, welcome to the Guild.

Hi. I just want to say I love that intro music. I felt like I was like Irishy kind of, you know, it was very cool.

That's true. Well, it's awesome to finally have you on the show, I guess. I haven't talked to someone from playwright since 2020. 2020 about. Almost five years ago. A little over five years. It's grown a lot. I know you have some new announcements, but before we get into it, I'm always curious when I look at your resume on LinkedIn, you've been a hardcore front end developer, it seems, for a while. How did you get into Playwright and automation?

That's a good question. I have such a long history, it would take the whole podcast. So I'll do a really quick thing. But I basically started web design 1997 back in the day and web design was rubbish. So I ended up leaving because the Internet was boring. And then I started building flash websites and WordPress websites and then like things changed and you know, the iPhone came about and all my websites were thrown in the bin because Flash didn't work anymore on anything. So I ended up restudying and I studied PHP and then I studied like, you know, Adobe Photoshop again and the web again because 1997, unlike, you know, 10 years later, the web is like a different web. So I was trying to get a job and it was really hard to get a job because they kept wanting all these like stuff that I had no idea what it was about. I knew how to HTML and I knew how to css and that wasn't good enough because back Then a front end developer only did HTML and CSS. They didn't do JavaScript. That was given to someone else, a programmer, they call that. Right? We were like the front end developer and then a programmer programmed like JavaScript. So I had to learn JavaScript basically and that was really difficult for me. It was only six years ago. Nobody would hire me six years ago because I did not have JavaScript. Even though my CSS skills were through the roof, that did not count. Nobody cared about that. So I did end up getting a job. After studying for about nine months, I went into studying full time. A front end tech degree and a full stack tech degree. Which part? Testing was part of the course, but it was like a very much ended at the end. Like, you know, this is something to do. It wasn't like a big part, but it's still a good enough part. And then I got a job in a company and I felt like, and I don't mean to be bad in any way, but I felt like they were doing things not as performant as they should have as they could be doing things. So they were doing a lot of manual things. And I was like, we could just run a script from that. I learned how to do that using Node. Just run the script and then it'll add the CSS file automatically for you. They weren't using components. We started adding components. They weren't testing. So we started to introduce testing and the funny thing was, and I know I'm going off course here and I'll come back, but the funny thing was that nobody wanted us to introduce testing because there was a bug fixing department and they were just worried about losing their jobs because if we do testing there's going to be no bugs to fix. Therefore these people are not going to have jobs. And that's the mental framing of like don't fix something that's working because we are employed by this anyway. We introduced testing and we had to do a lot of like work and convincing. Well, that was in one company. And then I changed jobs and went on to work in other companies. And testing was a very big part of like something that I was keen to bring in. Playwright wasn't around back. Back then I was using Selenium and Cypress and testing was something like if they could cut it out of the like because it was an agency, right? So if you've got like so many hours of work to do and this is all everything you're going to do for them, testing was the thing they would eliminate to cut costs and it was like, no. So we ended up trying to, like, not put testing in, as in don't tell them we're going to test, but test. And we had to do it that way because. Because otherwise companies did not want to pay for testing. So testing was something I was always kind of doing, but, like, I was very passionate in the front end area. So I was working a lot with front end static websites at the time and convincing everyone that we all need static websites and nobody believed me. And they said, that's ridiculous. Why would you want to do that? I feel like I'm always pushing for things. I'm always pushing people in the direction that they don't want to go in. People don't like change.

Yep.

So that was hard. It was great fun. I got then hired by the Nuxt team and I worked directly for nuxt. That was amazing. It was obviously fantastic. And then I end up working for Bit, which is completely diving into the deep end because I was like the very much Vue Nuxt developer. And then I was thrown into Reaction Typescript and I had to like, learn all this in a second. I was like, oh, my God. Like, I did touch React like some years ago, but that was different. React to change. Everything's different. So, yeah, and then we did a lot of testing there as well. We were testing components and making sure that every Bit component was tested. So that was more testing in there. So testing has always been part of my journey. And then the job just came up and someone said to me, you should apply for this. And I was like, but I don't even know what Playwright is. There's no way I could, you know. And I never ever considered myself as someone advocating for testing because I was just more like, making sure your front end website, everything is perfect. Like, I was like, make sure everything is perfect. And testing is part of that perfection. Right? Not just, you know. So that. Yeah, that was three years ago. Three years and a month ago. Which is crazy. It's like gone so fast. But I absolutely love what I do. It's great. Everyone, like, is like, no, we don't have time to test. No, it costs too much. No, we're not testing that. And I'm starting to see that more people are testing, which is great. There's still pushback. There will always be pushback. But I think with Playwright and making testing easier and fun, that's been my thing since I started making testing easier and fun. And I think testing is so much easier and fun. But there's still people out there not testing.

Love it. Love it. So, you know, you mentioned a lot. The first one was you were using Cypress and Selenium and then you learned about Playwright. I'm not putting down other tools, but what do you think separates Playwright from other frameworks, maybe, or who's the perfect tool, Persona that you talked to that like, oh, this team really would benefit from Playwright because of X, Y and Z?

I think when we were introducing Testing, the hardest part in the Selenium days, and this is going back, a good bit, was setup.

Yeah.

Setting everything up, getting it to work and just teaching. People didn't want to learn something that was hard to learn. They want to just be good at their job and get the job done. So if they're not going to be good at something, they're not really keen to take it on, so. And Selenium has been great in how it has got us to where we are today, but Selenium is hard and tricky and difficult to manage. Cypress was great. I always loved Cyprus and I was going to work for Cypress at one stage only. They couldn't hire in Europe. So, like, I love the Cypress team and, you know, I worked with them before on many occasions and stuff, and they're great. So Cypress is fantastic. There's. I've never have anything bad to say against Cypress. They have a different structure to how Playwright is, but that's technical details and stuff. And now it's like, I think Playwright is better, obviously. Obviously. Right. We're not going to debate that, but I have the right to be able to say that. I think that's kind of cool, but I just find that Playwright is very easy to get started, to work with, and it's grown so much. Like, in the three years that I've been there, we have evolved so much, and it's thanks to Cypress as well. They have, you know, brought these cool features out and we said, wow, look what they're doing. Well, we could, you know, improve Playwright based on what they've done. I always think, like, I love VUE and I love React, and VUE learns from React and React learns from vue. That's the way the world works. And if we didn't have competition, we wouldn't improve. So. So, yeah, But I think, in general, Playwright is. It's just so user friendly. It's just so nice to work with, and I think that's the win for everybody.

Love it. So, you know, you talked there. There have been a lot of improvements pretty much since you came on. I don't know if you've been pushing.

Improvements, but it seems like, definitely, that's awesome.

So what are the ones you're most excited about? I know I want to talk about mcp. Maybe we'll start with that mcp. What is it? Why is it helpful? Why do you think people should care?

Well, I definitely pushed for the mcp. That was definitely me. I was like, we need an MCP server. Come on, we have to do. And they're like, why? Why? Like, come on. And I was like, because I just used one to build a. What's that? Blender. I just use a blender MCP to build a leprechaun and I don't even know how to use blender. So this is cool. We need this, right? And they're like, what, what is mcp? MCP is the model Context Protocol. And it's. I like to say that it's. It's a way for the LLM. So we're talking about LLM, Large Language Model, or the Agent Copilot, or whatever you're using. It's the way for them to use a browser. So before, if you open up ChatGPT and say, can you open a browser and click on this button? It can't do it. I'd be like, I can't do that. Here's the link. Go do it yourself. Right? Which is fine because you continue the process after you've asked it to do whatever. But now with the mcp, because Playwright is about browser automation, it's about giving the agent the browser automation capabilities. And it opens up so many doors. There are things that I haven't even thought about that is possible, I see in a video just today of someone looking at the dev tools, the network requests for a website using Playwright, because Playwright can have access to the dev tools. So there's so many cool things. I actually used it for shopping, I think. I mean, I don't know why you'd want to do that, but I actually found it pretty cool and I just kind of told it to go and find the best price. And you know that we have to fill out the forms to find out how much it's going to cost to ship. And like, that's just boring. Well, someone just. The AI agent just filled out the form for me and said the shipping cost is going to be €30. I was like, ah. So now the price is not 500, it's 500 plus 30. Things like that, right? So the MCP server can basically open up a browser, click, click, fill out forms and use the Website like you were using it. So the agent now has capabilities of doing what you would do. So if you take it in testing, think about what a manual tester would do. So a manual tester would open the browser, open the website, click on the buttons, fill out the form, and check that form works. I don't know, Joe. I remember many years ago, and it's not even that long ago, but like building a form and then like, you know, running through everything, and then you get to like, the second last one, it doesn't work, and you gotta start filling out it all again. And it's like, oh, my God, find the bug and you keep going, right? And that's why Playwright came in, to kind of make that automation easy. And now you've got things like MCP can even just do all that for you. So the MCP server can do what you would have done yourself as a manual tester. But that's just one part. There are so many other capabilities. MCP is rocking the world right now. And I think everyone is like, I need to have an MCP server for everything, and I need to do everything with an MCP server. And I think you have to think about what the value is. And I will push everyone in the direction of you using it for everything as much as possible. Because I want people to see what's possible. And the only way you can see what's possible if you start testing things out. So the other day I was like, I need to generate some tests, but I don't even know what test to write. I'm like, go and test this website. And what would you do if you test the website, you open the link, you start clicking and you kind of say, oh, look, this website has a search feature. I'll test a search and I'll test this. I just got the MCP server to do it for me. I just told it now, just explore this site and come up with some testing scenarios. And it came up with some testing scenarios, and it came up with better testing scenarios than I would come up with, because I think, don't think about edge cases. I'm not a good tester. I'm a good advocate, but I'm not like a QA engineer who's been testing my whole life. I've been pushing people to test and teaching teams to test, but I have. I do not have the skills like a QA engineer sitting testing every single day. They are much more skilled than I am. So if I can get someone to help me, an agent and be server to Go and do all that for me and take that thinking away and test things and find things I wouldn't have thought about. I find that immense value.

Love it. So I'm still trying to have someone wrap their heads around it. Is it like you're using natural language and you go to a terminal, say, hey, go to this site and do a search. Or like, how do you interact with an MCP server and playwright rather than coding it up? I don't know if that makes sense.

Yeah, I mean, there's different ways. So think about, think about when you would get your test generated for you. So I'm going to. I'm going to say we're using VS code at Copilot, but you might be using whatever other tool you're using. But I'm just going to use those words because it makes more sense to keep it simple. So I opened VS code, I opened Copilot, and previously you might say copilot, generate some tests. And what Copilot would do is it would look at the code base, it would see it's a, I don't know, a nuxt application and it's doing whatever and it will start just generating some tests. And those tests are probably pretty bad because it doesn't know what locators to use. It kind of just makes it up and then you press play and the test fails and then you have to go and fix it and you spend ages fixing it and then you go, this takes too long. I'm just going to go and do it myself. That's a reality. Sometimes it does a good job, depending on your code base and how big it is. Now, when it comes to using the MCP for generating tests, there's a couple of things you can be very explicit and you can say, and I have examples where go to this URL, search for the Garfield movie and expect the Garfield movie to be on the page. It's a very simple test and it literally just goes and does it. Everything is correct. And the test works because when the MCP server opens the browser, it has access to the accessible tree of the elements. So it can see what elements it has on the page. So it knows the get by role main get by role button name, get by search, whatever, get by placeholder. And it can see all that. So it kind of remembers. It starts clicking, it starts doing all the actions, it remembers what it did, and then it's able to write a test based on what it just performed. So that's the kind of key to, like it has access to the accessible tree in the browser, like, rather than the code base that needs to be, you know, put together and, you know, turned into HTML after the React app is done or whatever. So that's kind of one way of doing it. You could also just do. And I have another video just released, what, two days ago, where I said, navigate to this URL. Explore. I actually said, explore this URL. Off you go. And then I have a prompt file. I do have a prompt file. Very strict instructions, very important to be strict and say, like, do this, don't do this, don't do this. And it then goes. Uses the MCP server to go to the website and it says, oh, I see this as a movie application. And then it looks at the accessible tree and it says, I'm going to use the search functionality, and it searches for the movie and it performs that search. And I have no code base in this. And I typically do it because maybe there are scenarios where you do not have access to the code and you have to test the website. And also just to make sure that this actually works the way it works. So it has nothing to go by, only the URL. And from that URL, it's able to go there. It's able to figure out what the website is. It's able to find something to test. And I've done a couple of videos. It starts testing the dark theme and light theme. I'm like, okay, yeah, that's cool. And it starts testing something else, and then it starts writing the code. And it's very impressive, but you have to be very careful and you have to really be clear with your prompts. The real important thing is how to prompt it correctly.

All right, so it sounds like magic. So is it using AI into the scenes, or is it because there's an API that it knows about? It knows. When I say open browser, it knows Playwright has this command that can open a browser or enter in text into a text field.

Yeah. So MCP is all about tools, right? So the Playwright MCP gives you access to tools like navigate, click. So things. Think of Playwright, what playwright can do. But now this tool of clicking, filling, typing, hovering, and the Playwright MCP server, when the agent opens the browser, it then looks to understand the website. Right. Can't see. It doesn't have eyes. Okay. Not yet. So it doesn't have any eyes, but what it can see is the accessible tree. So it knows that the first thing is the menu or the header. Then there's a menu, and inside the menu, then there's a Search field. And, and if I've given it instructions to test something, it goes in an order. It normally doesn't just like jump to the bottom of the screen. It kind of like runs along and says, oh, I see there's a search feature. I see there's a theme toggle. And because there's access to that, it's able to make the right decisions of what tool do I need to fill in the search field? Well, first I need to. And I actually have a video where it goes and starts to fill in Garfield, the movie Garfield, but it can't. And then it says, I'm going to take a page snapshot. That's a tool, takes a page snapshot and then it says, ah, I see I need to click to expand. Expand so that I can type in it. That's what a user would do. It would click and type. Now I can see that because I have eyes. So I would have clicked and then typed. But if you are blind and not being able to see, and basically we're going by tabbing and things like that, you would have had to click to then do that. And that's basically how it's able to do what it does by reading the snapshot of the actual website.

Nice.

If you understand what I mean by snapshot.

Yeah, yeah, totally. So is this meant for scale or to run your CICD setups or is it just as you're developing? You would just click it on terminal and test that new feature. Is it meant for like full blown regression testing, say?

That is a question for the future.

All right.

Because the MCB server is three, maybe four months old, right? It's still very early days and we are trying to improve it and make like. The idea is that this would be used for improving testing 100%. That is the idea. How can we improve it at the moment? There's a lot of work we still need to do to improve that and that's why we're always looking for feedback on how we can do it. For example, we have great tools for clicking, for filling. We don't have great tools for making assertions. So how can we think about and guide the agent to make better judgments when it comes to assertions? That's something we're looking into. So when would you use it? If there are different use cases, if you have no tests, this is a great way to get started, in my opinion. Do you need to understand what Playwright does? In my opinion, yes, because I think there should always be a human in the loop because you can just get it to navigate and generate and then you can press play and the test runs. You can even use the Trace viewer and actually go to it step by step. And it can look pretty good and you can just push that to production and that is better than nothing. But I don't think we're at the stage where you should be just pushing everything to production without looking at. So I really think that somebody who understands testing, who understands playwright, should be going through everything and maybe tweaking things or improving things or guiding the agent and saying that's actually, you've had a timeout there. Why did you add a timeout there? Take that out. We don't need that. Right? Otherwise you might find that my add stuff that you don't need again, I throw all that in the prompt. I was like, do not add timeouts unless you need it. Because Playwright doesn't need timeouts. It's auto waiting is already involved. And like, make sure you're using the right assertions. Make sure you're using row based locators. Right? I have to tell it all that. Otherwise it might just go, oh, I'll just use this locator. But yeah, it's. If you do it at scale, like if you have a big massive website and you ask it to go and test every single feature, it might get a bit lost because the context of the that the agent can take is only so much. So it's going to run out of of space and it's going to have to say, oh, it's going to summarize what it did and then it's going to have to redo it again and things. So I always like to keep things simple and say like test one functionality or three functionalities and then like I can say come back and do another one and reiterate and say, right, can you go and create three more functionalities on this website but have a look at the test folder to see what tests are already there. And now it has extra context to look at. It's able to say, oh, I see you already have a test for the search functionality. Let me go ahead and test the theme toggle. And then it goes and does that instead.

All right, so do you see that as almost people have unrealistic expectations for AI or MCP servers where they may get bad results and they may not know they get bad results because they didn't give it enough context? And like then they just say, oh.

It doesn't work a hundred percent. Like I was even doing a pair programming session with Airteam and it's a funny story because we were testing something out. We're testing the HTML report. Actually we opened up the HTML report and we writing a test for our HTML report. How do we test internally our HTML? And as we were testing it, it, the engineer was like, it's after hallucinating. It's after writing a get by test id. And it does not can't have access to it to get by test ID because it's accessible tree. It does not see test IDs right? And this is another thing, right? It can only see what the accessible tree shows and that does not show a test id. So he was like, this is hallucinating. And I'm like, no, have a look. It tells you it actually read the example test that was in the folder that was previously there that we created beforehand that has a test id. So it read that, it told us, it read that, analyzed that and then it said, oh, if this has a test id, I'll go ahead and use it. That's cleverness. But if you don't see and I don't understand what it's doing, you might think that it's hallucinating when it's actually not. Now another thing, the test failed, right? And it went and tried to fix it and the locator wasn't good enough. And the engineer said, you see, AI got it wrong. The it should have put a name in there. It's get by role. I can't remember what I was. Get by role, input text area, whatever. It should have a name. It didn't have a name. He's like put in name search. And I was like, okay, so we manually put in name search. You would press play in the test and the test failed. And he's like, open trace viewer, go to pick locator, find the actual right one. Maybe it's called search by or whatever. There's no name. Zer code is bad. So AI didn't hallucinate. It actually did its job correctly and it didn't put a name there because there was no name. It couldn't and it didn't make up a name. So it just said, well, you know, this is all I've got, right? And then we found that actually we need to improve the accessible roles of our HTML report. And actually. And then I'm going to have to pull a request tomorrow and actually fix that. So we learned something from that. Is that valuable? In my opinion, that was super valuable. Does that mean that we're going to get AI to write all Our tests, I don't know. We're certainly dogfooding and playing around with things and seeing what we can come up with. And then we learn where it lacks, what it has access to, what it doesn't, what we need to improve. And that's what we need people to do. Prompt is very important. We can run things. And also just picking the right model, sometimes we'll run it with. I personally like Claude and I'm using 3.7 a lot. I find if I use another model, it does weird things. I'm like, no, I don't. That's no. So I think changing the model and playing around with that and the prompt, making sure you have clear instructions and prompts is the key. But it's very easy to turn it down and say, this doesn't work and give up. And this is another thing. A very good play tester or someone who's very good, knowledgeable in playwright will turn around and say, it's quicker for me to write it myself. And you know what? It probably is, right? Just like it's quicker for me to write something in nuxt, because I am so good at nuxt. I wrote the docs for Nooks. I could just write something. I'm pretty good, right? But not everyone is at that level. And we're talking, I'm talking about building stuff for everybody, not for the expert in testing. Because testing covers so many roles and so many levels that people from a junior developer to a QA tester need to understand and learn, test and test their applications. So you have to decide when it's useful for you and how much of it to use in your job.

So is there any reason why someone couldn't do testing now? I mean, the barriers are so low. It sounds like, is it still like people still like, I don't care or is it making it where almost AI is not forcing them, but almost doing best practices. Hey, want me to run a test for you? Kind of deal prompting.

We're still a long way away from people actually just always testing because it's a mindset and people are not ready to change their mindset. And I'll tell you another story. I have a friend who I helped mentor into coding and he's very intelligent, very good, got a great job. And I gave a talk just over two years ago on the stage and I mentioned his name and I said I was talking about Copilot, trying to, you know, bring Copilot into his day to day and telling him that this is going to help him. This is going to improve his, his programming. No, I'm a really good programmer. I don't need copilot. And I constantly just, you know, nudge every time. Using copilot took him two and a bit years. He's now using copilot. He thinks it's amazing. He thinks it's the best thing ever. I'm like, why didn't you use a two and a bit years ago? Right? And that is because people do not have time to look into what they need to be able to use something that they don't know how to use. So when it comes to testing, I'm trying to get him to test now. I'm like, right now, the ed copilot, let's get you testing. And he's still not testing. So how long am I going to take? And I started mentioning about, oh, we're into MCPS now. Copilot's like, you know, that's old news. Now we're into mcps. You got to move on, right? It's me and you, Joe. We're on the edge of everything. Right? But others are not because our day to day is so busy that trying to find 20 minutes a day to just learn how to even just set up the MCP and it's so easy. All you need is 20 minutes. You've got the MCP set up and you can actually generate a test in 20 minutes. Some people don't even have that 20 minutes or that mindset to just go, I'm actually going to do this today. And that's why it's going to take longer than we would expect it to take or would want it to take for everybody to be writing tests. Because everyone's journey is different.

Absolutely. And I guess on those journey there's a lot of fear with AI I think still AI is going to replace me. I'm going to AI myself out of a job. You see all the headlines. People laid off because of AI. And you've mentioned multiple times that you need a human in the loop. Do you? I mean, I guess you're not a. You can't see five years down the road. But do you foresee always people. Maybe you can. Do you always see people being in the loop in this process? Or do you see just roles maybe are what we do changing at all, not being replaced?

I think it's absolutely the most difficult question to answer because six months ago, MCPS didn't even exist and this wasn't even possible. So it's really hard to turn around and say you know, in five years this is going to happen. People say in three months ago they said in six months time we're not going to need developers anymore. And you know, and my husband says it all the time. Oh, I just seen on the news they said that like, your job's at risk. And I'm like, I think everybody's job is always at risk.

Yep.

I think as humans, we have been constantly, throughout life and throughout history innovating and, and building things so that we can do less work. That's what we do. AI exists because we don't want to work. Nobody wants to work. We, if we could just all retire right now and just, you know, live on the beach on a farm, we would totally do it. We wouldn't even farm. We would like, you know, have someone else farming and we just like having the vegetables to eat.

Right, Robots.

Exactly. And the car industry robots have been building cars for longer than we even can remember. But it's acceptable. And we don't even think about it because, you know, if you go to Japan, you know, you've got robots serving you food. And I was in LA where there was a robot running the streets and crossing the road with something in its, in its trunk to give to somebody, like a delivery service. Right. So this all is happening around us. And does that mean that the delivery person might not be needed in the future? Are the drones going to be delivering in the Amazon packages instead of like the guy that drives the van and comes to my house every day because I constantly order stuff? We can't find drivers to drive, so there's a need for it. We can't find developers, so there's a need. And whenever there's a need for something, we always try and find a solution of filling that gap. So yes, I think there will be a lot of jobs replaced by AI, but I think there will be a lot of different jobs. And I think like, if you look at my children are 18 months, what are they going to be working at in, in 20 years? Who knows, right? I, there's no point in me teaching them JavaScript right now because we might not even need it in 20 years. And that's just something we cannot predict and we cannot, we cannot get ready for that. But what we can't do is sit back and fight and say, I'm not going to use AI. And I know that people out there say, no, I don't need AI. I'm good enough as I am. And that's perfect. You're, you know, I, I wrote HTML and CSS before editors existed, I did not need an editor. I was really good. I had a white blank piece of paper and I wrote and I was perfect. But VS code, right now, there's no way I could not use VS code and go back to those days. Everything is going to change and that does not. The editor did not mean that I. My job was gone because of it. So AI will. Will it eliminate some jobs? Of course it will. Just like, you know, the robot delivery service is going to eliminate the guy who rides the bike to deliver the parcel. Like, there are going to be changes, but if you don't use AI, I think you're going to be the first one that's probably going to lose the job because you're not up to date with what's happening and you can't help the company move towards the worlds that we're moving towards, whether we like it or whether we don't. AI is going to be part of every company. Every time you open your app, the mobile app, there's an AI. And in WhatsApp, now, I don't even know what it does, but it's there, right? It's going to be in everything. And Ryanair are going to have one and all the airlines are going to have one. It's just going to happen everywhere. So be part of it, embrace it, take it on, use it and give feedback and improve things. I think that's the best way that we can. The only thing we can do, really, because we can't predict the future.

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

I would say definitely take time to actually just go and do it. A lot of people say, oh, I need to get started. Just do it. Like, it does not take long. And there are many ways of getting started. You can just read through documentation which people hate, or you can just open the MCP server, install it and ask it to generate tests and then just read the code for yourself and then just start playing around with it. Press play in the VS code extension to be able to see the test in action. It's really easy. I don't think anyone has excuses. Try and find 20 minutes in your day, just 20 minutes, and just set that aside and just go and do it. And then send me a message and say, wow, I did it. And you're right, I'd like to hear that message. Or in 20 minutes I wasn't able to do write a test, I want to know why and I'll try and fix that. You can find me all over the Internet. You can find me on LinkedIn. I'm Debbie. Codes is my website. So if you just go there you'll be able to find some articles, links to YouTube, et cetera. And yeah, do reach out and do let me know how things are going. I think Playwright MCP is a game changer and I think everyone should be using it.

And you can find all the links for this in the comments 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 forward/a552 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 and 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@testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a chance 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 test guild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

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