Exploring Playwright and MCP with Debbie O’Brien

[00:00:06] In a land of testers, far and wide they journeyed. Seeking answers, seeking skills, seeking a better way. Through the hills they wandered, through treacherous terrain. But then they heard a tale, a podcast they had to obey. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild 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 them the secrets to behold Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. Oh, the Test Guild 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 them the secrets to behold.

[00:00:35] 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 is 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.

[00:01:06] Joe Colantonio Hey Debbie, welcome to The Guild.

[00:01:11] Debbie O'Brien Hi, I just want to say I love that intro music. I felt like I was like Irish-y kind of, it was very cool. That was very cool.

[00:01:16] Joe Colantonio 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, 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 like a hardcore front end developer it seems for a while. How did you get into like Playwright and automation?

[00:01:40] Debbie O'Brien 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 in 1997, back in the day, and web design was rubbish. So I ended up like leaving because the internet was boring. And then like I started to flash websites and WordPress websites. And then things changed and the iPhone came about and all my websites were thrown in the bin because flash didn't work anymore on anything, so I ended re-studying and I studied PHP and then I studied like Adobe Photoshop again and the web again because 1997 and like 10 years later, the web is like a different web. 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's about. I knew how to HTML and I knew had a 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. We were like the front end developer, and then a programmer programmed the JavaScript. 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 true to the root, that did not count. Nobody cared about that. 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 this is something to do. It wasn't like a big part, but was 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. They were getting 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 is run the script and then it will add the CSS file automatically for you. They weren't using components. We started adding components. They weren't testing. 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 to 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, but 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 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, we ended up trying to like not put testing in as in don't tell them we're going test, but test. And we had to do it that way because otherwise companies did not want to pay for testing. Testing was something I was always kind of doing. But like, I was very passionate in the front end area. 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. That was hard. That 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 ended up working for Bit, which is completely diving into the deep end, because I was like the very much view Nux developer, and then I was thrown into React, 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 had changed. 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 big component was tested. So that was more testing in there. 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. I don't even know what Playwright is. There's no way I could. 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. Not just-that was, 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 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 are still people out there not testing.

[00:06:15] Joe Colantonio Love it. Love it. You mentioned a lot that 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 persona that you talk to that like, oh, this team really would benefit from Playwright because of X, Y, and Z?

[00:06:35] Debbie O'Brien I think when we were introducing testing, the hardest part in the Selenium days, and this is going back a good bit, was set up. 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. If they're not going to be good at something, they're not really keen to take it on. 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 Cypress and I was going to work for Cypress at one stage, only they couldn't hire in Europe. I love the Cypress team and I worked with them before on many occasions and stuff and they're great. So Cypress is fantastic. 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. 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 thanks to Cypress as well. They have brought these cool features out and we said, wow, look what they're doing, well, we could 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.

[00:08:11] Joe Colantonio Love it. You talk 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. 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?

[00:08:28] Debbie O'Brien 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? I'm 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 Leprechaun. And I don't even know how to use Blender, so this is cool. We need this, right? And they were like, what? What is MCP? MCP is the Model Context Protocol. And it's, I like to say that it's a way for the LLM, so we're talking about LLM large language model or the agent, co-pilot, or whatever you're using, it's the way for them to use a browser. Before, if you open up ChatGPT and say, can you open a browser and click on this button, it can't do it. It'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 is 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 DevTools, the network requests for our website using Playwright because Playwright can have access to the DevTools, 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 euros. 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 fill out forms and use the website like you were using it. The agent now has capabilities of doing what you would do. If you take it in testing, think about what a manual tester would do, so a manual tester, you 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 running through everything. And then you get to like the second last one, it doesn't work. And you got to start filling it out all again. And it's like, Oh my God, find the bug and you keep going. 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. The MCP server can do what you would have done yourself as a manual tester. 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 do everything with an MCP server. And I 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 is possible if you start testing things out. So the other day I was like, I need generate some tests. But I don't even know what test to write. And 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 the search, and I'll just test this. I just got the MCP server to do it for me. I just told it. Not just explore this site and come up with some testing scenarios. And it came up with testing scenarios, and it came with better testing scenarios than I would come up, because I 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 do not have the skills like a QA engineers sitting, testing every single day. They are much more skilled than I am. If I can get someone to help me, an agent, an MCP 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.

[00:12:13] Joe Colantonio Love it. 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 and 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.

[00:12:27] Debbie O'Brien Yeah, I mean, there's different ways. Think about when you would get your tests generated for you. I'm gonna say we're using VsCode 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. I opened VsCode, I opened Copilot and previously you might say Copilot generates 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 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. That'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. It knows get by role main, get by roll button, name, get by search, whatever, get by placeholder and it can see all that. It kind of remembers what 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. 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 put together and turned into HTML after the React app is done or whatever. 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 profile, very strict instructions, very important to be strict and say like, do this, don't do this. Don't to 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 said, I'm gonna 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. It has nothing to go by only the URL. And from that URL, it's able to go there. It's able figure out what the website is, it is 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, 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 really important thing is how to prompt it correctly.

[00:15:24] Joe Colantonio 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?

[00:15:38] Debbie O'Brien Yeah, so MCP is all about tools, right? So the Playwright MCP gives you access to tools like navigate, click. 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. 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 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 had 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 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. 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 them. Do that. And that's basically how it's able to do what it does by reading the snapshot of the actual website. If you understand what I mean by snapshot.

[00:17:12] Joe Colantonio Yeah, yeah, totally. Is this meant for scale or to run your CI/CD setups, or is it just as you're developing, you would just click it on terminal to test that new feature? Is it meant for full-blown regression testing, say?

[00:17:25] Debbie O'Brien That is a question for the future.

[00:17:26] Joe Colantonio All right.

[00:17:28] Debbie O'Brien Because the MCP server is three, maybe four months old. 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 tool for making assertions. 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. 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 it. 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 good. You've had a timeout now. Why did you have a time out there? Take that out. You don't need that, right? Otherwise you might find that it might add stuff that you don't. 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 all these locators, but I have to tell it all that. Otherwise it might just go, oh, I'll just use this locator. But yeah, it, 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 that the agent can take is only so much. So it's going to run out of space and it's gonna have to say, Oh, it's going to summarize what it did. And then it's 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.

[00:19:58] Joe Colantonio All right. 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 got bad results because they didn't give it enough context and like then they just say, oh, it doesn't work.

[00:20:12] Debbie O'Brien 100%. Like I was even doing a pair programming session with our team 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're writing a test for our HTML report, how do we test internally our HTML? And as we were, testing it, the engineer was like, it after hallucinating. It's after writing a get by test ID and it does not, can't have access to get my test ID because it's the accessible tree, it does not see test IDs, right? And this is another thing. It can only see what the accessible tree shows and that does not show a test ID. 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 idea. It read that it told us it read that. Analyze 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. And it went to try to fix it and the locator wasn't good enough. And the engineer said, see AI got it wrong. It should have put a name in there. It's get by role. I can't remember it 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 named 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. Our 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 did not make up a name. So it just said, well, this is all I've got. And then we found that actually we need to improve the accessible roles of our HTML report and actually in that I'm going to have to pull requests 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 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 needed 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, that's no. 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 Playwright tester or someone who's very good knowledgeable in Playwright will turn around and say it's quicker for me to write it out myself. And you know what? It probably is, right? Just like it's quick for me to write something in Nuxt because I am so good at Nuxt. I wrote the Docs for Nuxt. I could just write something, I'm pretty good. But not everyone is at that level. And we're talking, I am 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. You have to decide when it's useful for you and how much of it to use in your job.

[00:23:39] Joe Colantonio 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 AIs not forcing them, but almost doing best practices. Hey, want me to run a test for you? Kind of deal, prompting.

[00:23:55] Debbie O'Brien 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 and very good, good, 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 co-pilot trying to bring Copilot into his day-to-day and telling him that this is going to help him. This is going improve his programming. No, I'm a really good programmer. I don't need Copilot. And I constantly just nudge every time using Copilot, took him two and a bit years, he's now using Copilots, he thinks it's amazing. He thinks it was the best thing ever. I'm like, why didn't you use it two and a big years ago? 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 them to test. Now, I'm like, right now you need Copilot. Let's get you testing. And he's still not testing. How long am I going to take? And I started mentioning about, oh, we're into MCPs now, Copilot. That's like that's old news now we're in the MCPs. You're going to move on. It's me and you, Joe, we are 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 gonna do this today. And that's why it's gonna take longer than we would expect it to take or would want it to for everybody to be writing tests because everyone's journey is different.

[00:25:33] Joe Colantonio 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. 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? That's all not being replaced.

[00:26:00] Debbie O'Brien 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, in five years, this is going to happen. People say in three months ago they said at six months time, we're not going to need developers anymore. And my husband says 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, I think as humans, we have been constantly. Throughout life and throughout history, innovating 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 if we could just all retire right now and just live on the beach or on a farm, we would totally do it. We wouldn't even farm. We would like have someone else farming and we just like having the vegetables to eat, right?

[00:26:49] Joe Colantonio Robots.

[00:26:50] Debbie O'Brien 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 if you go to Japan, you've got robots serving your food. And I was in LA where there was a robot running the streets and crossing the road with something in its trunk to give to somebody like a delivery service. 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 find developers. So there is a need. And whenever there's 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 a lot different jobs. And I think like, if you look at my children at 18 months, what are they going to be working at in 20 years? Who knows, right? 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 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 are there and say no, I don't need AI. I'm good enough as I am. And that is perfect. 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 VsCode right now, there's no way I could not use VsCode and go back to those days. Everything is going to change. And that does not, the editor did not mean that my job was gone because of it. So AI, will it eliminate some jobs? Of course, it will. Just like 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 part of every company. Every time you open your app, the mobile app, there's an AI in WhatsApp now. I don't even know what it does, but it's there, right? It's going to in everything. And Ryanair are going to have one and all the airlines are going to have when it's just going to happen everywhere. 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.

[00:29:24] Joe Colantonio Absolutely. Okay Debbie, before we go, is there's 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?

[00:29:32] Debbie O'Brien 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 reach your 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, 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 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 and you can find my 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.

[00:30:27] Joe Colantonio And you can find all the links for this in the comments down below.

[00:30:31] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguild.com/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, 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.

[00:31:05] 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 at TestGuild.com where you become part of our elite circle driving innovation, 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.

[00:31:48] Oh, the Test Guild 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 them the secrets to behold.