Playwright, Cursor & AI in QA with Ben Fellows

In a land of testers far and widely journey, seeking answers, seeking skills, seeking a better way. O the Testicular Mission Testing Podcast guiding testers with our nation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Testicle Await podcast.

Are you spending hours writing page objects or reviewing endless PRs only to feel like you've fallen behind? Imagine cutting that time down to minutes without sacrificing quality. That's the power of AI in qa, and today we're diving into it. Hey, I'm Joe Calantonio and today you're in for a treat. If you've been hearing all the buzz about AI in QA but still wondering what it actually means for your day to day testing, you'll want to stick around. Mike S. Ben Fellows, founder of Loop QA speaker and workshop leader, has been helping QA teams and directors of testing to get hands on with AI, playwright and augmented coding. In this conversation and demo, Ben breaks down what's hype, what's real, and actually shows how AI can slash hours of tedious coding into just minutes. We're talking practical demos, page objects in seconds, new roles for QA, and even what's coming next in 2026. Trust me, this is one of those episodes. I think it's going to change how you think about testing forever. Just grab your favorite cup of coffee or tea and let's do it. Hey, quick question. Are you overwhelmed by test tool research? You're not alone. Choosing an automation testing tool can be a rabbit hole with hundreds of opinions, each promising to be the best, but none tailored to your team's specific goals. Stack or budget. And that's where the free Test Skill Tool Matcher comes in. Answer a few quick questions, think test, type, budget, tech stack, and instantly get a personalized shot list from over 300 trusted tools. This will save you weeks of demos and sleuthing. Get expert curated recommendations backed by insights from our podcast, interviews, blog posts and webinars. Make confident decisions faster. Think of this as like a G2 product hunt test Tool Encyclopedia of Test Tooling Awesomeness so you're ready to cut through the clutter. All you need to do is go to test guild.com, click on the Tools menu and select the Tool Matcher to find your perfect test automation tool in seconds. Powered by the Test Guild community, where automation pros get smarter faster. Check it out. Hey Ben, welcome to the Guild.

Hey Joe, I appreciate you having me.

Really excited to have you. I've been following you for a while and I've Been seeing a lot of posts on LinkedIn about. I guess it's the workshop you're given. A lot of industry leaders like Jim Hazen, I think Butch. What's his last name? Mayhew.

Mayhew, yep.

Has been recommended. Wow, this was a great workshop. I know you've been talking about playwright for a while, but now you're coming in with AI as well. So thank you so much for joining us today.

Yeah, happy to share more.

Awesome. All right, Ben, I guess before we get into it though, a little background for the folks that may be new to you, like, how do you get into automation? And maybe a little bit more like, how do you found your company, what that's all about as well.

Yeah, for sure. So I think, like nearly everyone in qa, particularly in the States, I got into QA accidentally, just kind of through lived experience, randomly. I was in politics in college, worked on Capitol Hill for a couple years, had the opportunity to join a startup, sort of got to join a tech team and very much that kind of learned to build a plane and fly it at the same time experience. We built a box office management solution in Ruby on Rails and during that time just really had death by a thousand cuts like it was. We would release. No matter how much testing we did, we would always break something and really got to see firsthand the emotional toll that qa, when done poorly or not, you know, development, when done poorly or couldn't cause on a team. So that set me on a journey when I decided I want to start my own company to figure out, like, what is this methodology? What are these practices? Why is this so hard for technology companies? Founded A QA Company 6 1/2 years ago now, you know, knowing what I know now, just wildly naive, maybe in some ways. And then in the last couple years, have really been trying to understand the impact of what I call augmented coding, or what a lot of other people called AI and stuff like that and its impact on qa. Have a ton of thoughts and would love to get into it on this and show a little bit of some of what we're doing in our workshops and kind of what we're talking about.

Love it. Love it. So I guess before we get into it as well, why playwright? It seems like you were. You jumped on board playwright pretty early as well.

Yeah. So basically when we first started off, we were doing a lot of manual testing, and from this UX UI perspective, I kind of focus on three traits when it comes to qa. It's emotional intelligence, critical thinking, analytical Ability and ambition. Right. Why Playwright is simply because we were using a private tool originally when we first started a company called Essential Test. Great team, but they had some limitations. Shout out Brian behind that team only works on PC. A couple other things with some of our clients say, hey, we really, we want more of an open source solution. So we had jumped over to Robot Framework. We're using the Playwright library within Robot Framework. And then we were like, well, why not just start using Playwright itself? The thing that struck me immediately about Playwright when I started using it comparatively like Selenium and Cypress and some of the other ones was flexibility of locators. Like, there was never something I couldn't get access to in the dom. The ability to run in parallel by default, the ability to have multiple context windows, multiple browsers up and going at the same time and be interacting during the test. So really kind of accidentally got into it, but then fell in love with it very quickly.

Absolutely love it. Love it. All right, so before we ease into the workshops as well, I'm trying to tease it out. I know you also are doing, I think like one on one director sessions as well. And I'm just curious to know from your point, before we go into like a demo mode, is there a common thing you see QA leaders struggling with that's common with AI or misconceptions?

Yeah, there's a lot actually, because there's a lot of pressures. I think that the biggest thing with AI to understand from a QA perspective is that there's really two ways that I think we see AI affecting qa. There's like agentic browser based agents that are opening browsers and driving the browsers and using image and they're doing testing. And I think a lot of private companies are selling at best helpful solutions, at worst kind of magic solutions of just this idea of like, oh, it can open the browser and do all your tests. I think that there's some interesting stuff happening there, but at the same point, I think it's not really production ready or enterprise ready, at least as far as I've seen with some of the MCP stuff that I've played with. It's slow and expensive to run, but there's a lot of promise. And then there is basically what I want to talk more about, which is AI is kind of a coding tool and understanding how do we use traditional test automation but use AI to help when it comes to these director conversations, I think they're getting a lot of pressure from boards to say AI everything. And I think that that's probably the wrong approach. I think thinking about AI's targeted implementations of bottlenecks is really the right approach. Team roles and team size. I'm seeing a lot of pressure on figuring it out because I just had a conversation with someone yesterday who were like, I cannot keep up with the PRs anymore. My team is producing so much more code and it's high quality code, but I can't keep up. And I was saying, you know, yeah, one of the things that we're seeing is actually a readjustment in how many, you know, code reviewers you need comparatively to people who are producing the code. Do you need more of these sort of different roles and that roles? And it's been interesting because some companies really open to this idea. We fundamentally need to rethink roles and responsibilities and the distributions of those roles. And then other companies, their management is saying use AI, but they're much stricter. And so it's like this kind of challenging balance. And so, yeah, a lot of different thoughts. Happy to go in any direction you find most interesting there.

All right, I guess the first one, why is there more code? Is it because they're using AI to generate the code now and that's why there's so much code?

Yeah, exactly. So basically, and what I can give a couple demos of, for example, is to me, the best use of AI today is to think about it as a productivity tool, right? There's so many different narratives about AI. There's so many different narratives about kind of what it can do. And the thing that I think it does very, very, very well today is do something like, okay, as an automation engineer, I have to write a class or a page object model from a website that might take me three, four hours to do now. And I can show you this, it would take about 30 to 40 seconds. Six months ago it would have gotten most of those locators wrong. But today, with some of the tooling and the models that they where they are, I'm seeing roughly 80 to 90% of the locators are accurate. And then I'm just debugging the ones that are not accurate. So now that three, four hours of work is compressed down into, let's call it 15, 20 minutes, if I'm done with that ticket and I ship it, I'm now onto that next ticket. And so across our projects, we're seeing anywhere from a 3x to 5x increase in high quality code per engineer per project. And so I know the old adage of more code isn't necessarily A good thing. But what I'm trying to explain to people is, no, this is the same code that would have been produced by that engineer. It's just happening that much faster.

I love that. That's a good point. So along those lines, Ben, do you see people more curious or skeptical when you bring AI into QA, especially on LinkedIn, I would think know how some people are really like either anti AI, a full blown AI and kind of get into like AI, I don't know, chaos sometimes.

Yeah. So what I would say I've experienced over LinkedIn is kind of, you know, the five stages of grief. Right. Or the five stages of change or whatever. In the last couple years posting about AI, I feel like I've sort of seen this unfold over it directly in front of me. Right. And I forget the order of the stages, but it's like denial.

Anger, then kind of acceptance, but doesn't apply to me. There's these five stages. If I posted about AI year and a half, two years ago, it was a lot of just, you're a charlatan, you're kind of crazy, you're dumb, blah, blah, blah. If I post about AI today, it feels like the industry has pretty much come to grips with this idea of no, it's, it's a useful tool and it's here. I think that the challenge with AI is it fundamentally changes our jobs from people who write code to people who review code. For me, I love that because I'm not a huge, like, I don't get a ton of joy in the writing of the code and I really enjoy thinking about the architecture and reviewing the code. There's a lot of humans out there though, who really love the art of writing code. And I think that that's where there is legitimate sort of emotion around this idea of like it's taking something from people that like 20 years of their career into perfecting and have a ton of pride in a hundred percent agree.

So that's why I think seeing is believing. I think some of these demos that people have been raving about on LinkedIn is going to help the audience as well. So you talked about page objects, and I know some people just love creating page objects and I'm just curious to know then how AI can help accelerate that or maybe make it easier, better for them.

Yeah, for sure. So one of the things I cover when it comes to page objects, so here's like a kind of a demo app that I play with. It's just something that I like have built myself. It's how I kind of try to manage a bunch of my relationships and stuff like that. You know, your traditional way you're going to approach this situation is you're going to open it, you're going to go through the dom, right? And you're going to either have a framework for this, you're going to go through yourself, and you're going to basically write all your locators right now, depending on the circumstance. More and more, I'm pushing for QA teams to have direct access to their repos because you don't even really need to open the DOM anymore. So let's start by assuming that the QA team has access to their repo. In this repo, we have a test folder with a Playwright suite in it and then you have your code base. Let's assume that I'm a QA person being told I want to write my page object model for the dashboard. So we're going to go over to the prompt, we're going to say add a POM file for the dashboard and we're going to give it some context of what the actual dashboard component is that we want to do it for. And we can go, and we'll pull it in here, oops, wrong file here. And what it's going to do is it's going to add a page object file for my dashboard. And what this is, is this is taking what is something that's probably two to three to four hours worth of work and it's going to do it in probably two minutes, right? And so, and we're not even opening the browser, which is amazing. We're actually just literally having, we're pointing cursor at the component, it's going to go read the component and it's going to write a page object model file that is actually fairly good. Now we could add a lot more context. We could do stuff like cursor rules. But you can see this is a five word prompt. Like a lot of people think, oh, we need perfect prompts. And actually like, to me, what I tell people is as long as you have an engineer who understands what the output should be and they're evaluating the output against it, the prompt MA doesn't really matter nearly as much. We could make this probably better, but just for the sake of this demo, and what I always start off with is basically giving this. This doesn't say playwright, this doesn't say anything about best practices, this doesn't say anything about how you want to do it. And for the most part it's going to do a very, very good job. We could offer it more context. We could put in the playwright, you know, locators, URL. We could do some of these other things. And these are all things I try to cover in the workshop about how these things go. But what the output is going to be pretty good. And so you can see it wrote 529 lines. We're going to open this and you can see it has a dashboard page class, which is exactly what I would expect. It's got all your locator read only is defined and here you have your constructor. And this is exactly how I would write test automation. Now, some of these things I don't love off the bat. Looking at this, I don't really love the use of dot first here. So that would be something that I would immediately call out, I'd go through and we can go and sort of start to review this and edit this. But the fact is, is if I tried to sit down and just write out this code, I mean, you're talking hours of work and it's done and it started to add methods. It's added a method for get total contact scout, get needs attention, count all of these different things that I would need to use if I was writing test automation. Right. If you think about interacting with this page and we can take it a step further though, and while it works and I'll turn it back to you to ask a question, we can actually take it a step further and we can actually say, okay, not only have we gotten this productivity boost from this, we're much faster. Let's go ahead and let's tell it. Add test IDs to the component and update the POM. And so this is the thing that's really happened in the last three, four months is the AI is actually good enough now to update a front end component without breaking it. If I had given this prompt six months ago to this, it would have broken the entire front end component. Now I can give this prompt and 99 out of a hundred times it's just going to update the front end component with test IDs, update the palm to use it, and the front end component will not be updated in the lease. So now not only have we been much more productive, we're actually going to have a significantly less flaky set of test automation as well because we have test IDs that are independent of locators changing and anything else. So I'll pause there because it was a lot of information kind of what questions Thoughts, concerns come to mind so far.

So the first one with the locators, do developers usually have an issue with that? Is this a culture change or am I. I haven't been doing development five, six years. Maybe this is the norm. But is this the norm where your testers work directly in the repo Azure developers and they're able to make change.

To the actual production code completely company specific? Some companies very comfortable with this change, other companies very not comfortable with this change. You know, and one of the things that I talk about is kind of being qa, we always focus on the pragmatic reality compared to the theory. We could all understand the theory, but then we're oftentimes put in situations where the pragmatic reality is a bit more challenging. Let's assume that you didn't have access to the code. What you could do is you could just copy and paste the whole DOM directly into the agent and the same concepts apply whether or not you do it. And so what I try to do is with these workshops, I try to say, in a perfect world, look at how amazingly fast and stable this can be. But yeah, most companies, you know, maybe their automation suites no longer in their code base, maybe it's not a monorepo. And so there's a lot of things around this that can throw flags. And so maybe it's just part of this that I'm showing could apply. Maybe it's just, hey, I'm going to copy the whole DOM and make locators from it, but I'm not going to get the benefit of test studies, right?

Absolutely. And I think what's important is, as you mentioned, the person needs to know what they're doing. A lot of people, I think vibe testing, I don't know if you would call this vibe testing, but you're not just taking it at faith what it's doing, you're actually looking at it, what it does. And you have to, as a tester, understand the code still. It's not like saying, no, encode is obsolete and you still need to understand not only the code, but the domain as a tester. Is that correct?

Yeah. So. And I always call it code augmentation because I feel like vibe coding came out of there was, I forget who was termed it, and it was originally not sort of a derogatory term. But then all of these, like, developers over the last six months, 12 months, they would always be like, why do real coding? And all these other vibe coders, it's not real. And so it's like to Me. It's like. What I'm trying to say is, okay, Vibe coding is like, whatever this is augmented coding, where it's like, we're using these tools to do the same quality of code that we'd be otherwise doing, and then we're just doing it much faster, right? And so what we can see is. And once it starts to finish its. Its test IDs, and we can go look, right, it's the same class, the same style, and everything is just added a test id, and then once it finishes it, we can go to the Palm and do it. I don't know that I directly answered your question. I think I got a little bit too hung up on the Vibe coding piece. But that is just the one thing that. Yeah, it's like the thing that I'm trying to tell people is the actual output of the code is the exact same. It's just a question of how quickly you get there.

Love it. Love it. Okay, cool. So how does MCP change? Is this using mcp? A lot of people are talking about playwright. MCP is. It knows playwright in context. Like, does mcp. What does MCP do? Or now you're using MCP behind the scenes there.

Yeah, for sure. So this is nothing to do, an MCP server. So this is just simply using Cursor to interact with a code base and do prompting, essentially. And you can see, by the way, as we finished. Right, so you have all your test IDs now. So now we have a page object file that, you know, didn't exist 10 minutes ago and also didn't have any test IDs in the front end. In less than 20 minutes, we have a page object file that has test IDs for every major thing, has methods for every major element, and it has test IDs. When it comes to the use of an MTP server, this is where it starts to become interesting. And in my perspective, you start to be right on the edge of like, is it production ready or not? What you're doing here with Cursor is just like augmented coding. You have a human who's still going to go interact with the Internet. What an MCP protocol is doing, as far as I understand when it comes to, in general, is mcp. Protocols basically are a set of protocols that allow AI to understand the tools that it can do to interact with other things. Specifically with Playwright, it allows AI to drive a browser. Right. And so. But you could also use MCP to interact with jira, all these other things. There's a lot of Companies, particularly private companies that are trying to use MCP in the world of QA to say, why would you yourself go navigate to the dashboard to write test cases when you can just open an MCP with Playwright and you could say, go to the dashboard on here and write test cases by what you see underneath the surface. All it's doing is it's basically just opening the browser, it's navigating to it, and it's, in theory, writing the test cases. And there's a lot of ways you could do it. You could use, like, Claude's computer use, you could use a couple other ones. But Playwright has a whole library designed around interacting with the browser. So what they've done is they've given AI the ability to drive the browser. And this is where you start to get into that concept of like, how, quote, unquote, magical can it be? Right? Because in theory, with an mcp, you could say, hey, open my app and write an entire test suite from what you find. Right? And in theory, I've turned off these emojis so many times, but they stay on. In theory, an MCP system can open the browser, can navigate through everything, and it can basically write your entire test suite. Does it work that well? My experience, no. Is it really interesting, though, for one off use cases and like, am I. Do I see a world as it gets better and better where it can take on bigger and bigger tasks? Absolutely. And so it's one of those areas where I think that one of the challenges with AI is trying to figure out what should I be keeping an eye on for the future and what's useful in the future. And, like, where is it really Excel right now? And so my perspective is this code augmentation it crushes right now. It could be taking traditional test automation suites and be making you exponentially more productive at it. This MCP side of things, I'm keeping an eye out. I love Debbie o' Brien's demos that she's doing. I'm like, okay, at some point in the next six months, to 12 months, to 18 months, we might be flipping away from test automation with the DOM to test automation through mcps. But I'm still under the camp of I'm waiting to see it work at scale. It's a little too expensive and slow for me. And so I'm still trying to figure that out.

I have been doing silly things with it. I have a local application I created to get stats on me from Libsyn, because you need to manually log in and have an assistant that does it. Now I just have a button they put in the name and it uses the Playwright MCP to go and just grab the stats and throws it into the little app I have. So it's pretty cool.

Well, and it goes back to what's interesting is Playwright. You know, Playwright has two libraries. You have Playwright Test and you have Playwright Core. And like, what's fascinating about. And once again, I only know so much about Playwright. The team itself knows more. But Playwright as a tool is like, suddenly you have all these agents interacting with the browsers. And Playwright across all these agents seems to be really the default way that a lot of them are choosing to interact with the browsers. And so what's interesting is there's almost now two communities of Playwright users. There's the traditional test automation users who are like, hey, we're here and then we're qa. And then there's all the Playwright users that are coming in because they're doing like business cases or like what you're saying, hey, here's a non automation based use case. And I sort of see maybe from the outside and I know nothing about the conversations. I wonder how much tension there will be on the Playwright team at Microsoft to start to be like, wait a second, which one has more business use cases? And trying to figure that out. And I'll be curious to watch them navigate that.

Do you worry about Microsoft owning Playwright? Random question.

Yes, in some ways. I think there's always risk with so many of the tools that we use that they're actually owned by private companies. I think that there's pros and cons to it. On one hand, I know the team well and I like, I'm stunned by how well the job they do and how much produced. And like, it goes back to like, I know the Selenium folks. I don't really know the Cypress folks as much. There's a reason why Playwright became so popular so fast. On the other hand, I think there is inherent risk to a private company. But no, the short answer is I don't worry too much about it. I just always try to also have backup plans in the back of my mind. But yeah, no, I don't worry too much about it, to be completely honest with you.

And so just to clarify, this isn't Playwright only, right? Could this be approach also agnostic, where it doesn't really necessarily matter? They could use Selenium or whatever puppeteer if they had to.

Yes. This is language. This is language agnostic, this is framework agnostic, et cetera. So like Cursor, which is also a private tool. Right. Sam goes back to that idea of, like, you know, I'm basing a lot of this stuff on, like, cursor, which is a private tool. You know, the most important thing is understanding the models that we're using. So, like, I tend to use Cloud Force on it, which is a premium model. But, like, GPT5 is obviously out. The biggest takeaway that I would say also is, like, if you put this prompt in with an older, cheaper model, it will not perform nearly as well. So if someone says, joe, I watched this interview and this guy lied because I did the same thing and it didn't perform, first question I always ask is, which model are you using? Because, like, if you're using a cheap model, you're not going to get nearly the same level of performance. So, no. Any language, any framework, this is code in general. This has nothing to do with Playwright. And like, one of the real benefits, particularly when you have well documented stuff, is if it ever does, for some reason, struggle with what, what you're trying to do. One of the great things about Cursor, and this is not limited to cursors. If I pull up the Cypress docs and I put it right there, like, it'll go. Just read the page and it'll figure out what to do. Or you can go and you can index the docs and it could just go from there. So, yeah, completely agnostic.

Love it. Good point about the model. This drives me nuts. You see people, once again on LinkedIn that will pick holes at using AI, but they're using, like a model that wasn't designed to do what you're doing. I don't know if that makes sense, but they almost make it like a strawman when you're like, well, that's not even the model I'm using. So it doesn't even. It's not helping your point, basically.

Well, and it's such a learned skill, and I didn't really appreciate this until like a month or two ago. And then as I've started to more and more appreciate it when it comes comes to these webinars, a lot of engineers that I'm working with, they want to, like, memorize prompts, they want to memorize this stuff. And the challenge with this is like, doing augmented coding is really a skill that you learn over time, and you start to understand the patterns of how AI behaves and you start to sort of understand what you can and cannot do. So, for example, like, it's going to Research a lot of the files, but it struggles still with huge file sizes, like it just does. And there's a lot of these things that you just pick up over time where you're like, okay, so this is how I have to start to think about like architecture and the decisions. And so what I'm trying to do with these workshops is focus on kind of inspiring people to go in a direction, then having people come out of them with like a memorized set of prompts and stuff like that. Because just using this tool, I mean it, I would say it took me a couple hundred hours before I fully was like, okay, I got this, I'm going, I'm moving forward.

Absolutely. I guess another point is I think we may have, maybe I'm wrong, maybe you don't agree with this. A lot of testers have and said, oh, we're developers now, so we need to write production ready code. So a lot of people complain that oh no, the code isn't beautiful or writes a lot of code, but this isn't for production. So as long as it works, I would think it's fine. Do you have any thoughts on that?

I do. I think that it writes better code than people expect. It can, particularly if you know what kind of standards you want and you just start to give it feedback. The other thing that I will say that I find really interesting is that, you know, there's less and less barriers between QA and developers when it comes to like code and code practices. So for example, if I said something like, find me the file that handles goals.

On the front end. As a qa when I'm getting into a project, I now have a tool where I can just spend like an hour or two just understanding the code base that I'm interacting with. And this does a really fantastic job. And so when it starts to think about like, okay, what are the decisions the dev made here, what are the code quality things that the dev did, I can even ask it questions like, hey, based on how you see this implementation, what things do you think I should actually test? I mean, obviously I'm going to still use my brain and critically think. And the danger here is it's good enough to where maybe people start to over rely on it. But within 30 seconds it found the component file where goals was. It then gives me a nice little summary, gives me the key features. It then also tells me some other files where the goal functionality is used and which is all accurate looking at this and then I can say something like, what is the unit integration test? Coverage of it and it can probably identify that there is none. Now funny, I've hit a spending limit. Side note, this stuff's expensive. So actually this raises a really interesting point. I am spending hundreds of dollars per month per engineer on this. And so like our tools budget is going way up. That being said, one of the things about this, if you go back to those productivity pieces, I don't have to hire as many humans anymore because I am seeing that 3 to 5x. And so there is this really interesting larger question of like okay, shaping of expenses and stuff like that. Like as you saw, I mean my spending budget per engineer is upwards of like 250 and I just hit another limit. So it's like I'm also running though the most expensive models besides Opus. Opus is the most expensive and this is kind of second most expensive. But the point that I was trying to make is like I think that qa, you should spend time understanding the code because you now have this thing that can actually inform you of the decisions that were made and it should no longer be the black box that it'll lens wise.

Yeah, I love it. And I guess it also gives suggestions. You know, they just check this. In what areas do you think like you said, don't have code coverage or should I look at more for, you know, whatever your goal is. But obviously it's going to give suggestions. But you as the human needs to say, well that's a good one. That's not a good one. That's an okay one type deal.

Yeah, 100%. I mean and it goes back to, I think that like everything, unfortunately it might bake engineers that struggle, it might introduce more bad code. But I think for engineers who really are your great engineers already, they'll just have that much more impact on your code base and your projects.

Now do you recommend teams use like a template in cursor? So all the code is similar. Like you are like it defines a Persona or a level. You're checking for security issues so that anyone on your team that prompts is going to have the same style, the same code, the same objectives.

I don't know if that makes sense.

But I think this. Cursor templates, right?

Yeah, cursor templates. There's cursor rules which you can do where you can basically say anytime this happens, always do this. So for example, more and more projects are publishing cursor rules. So this project uses a convex backend and so they actually convex publish cursor rules for you of like here's all Your instructions for how you should do best practices with convex. And that way whenever you're working you can always just default back to it. To your point, you can extend that. I always find cursor rules to be helpful, but for whatever reason it doesn't always follow the cursor rules maybe as directly as I would expect. So I do think it goes back to like the hesitancy here or the danger here is it is such an endorphin rush now because you can produce feature, feature, feature and you don't want to stop an ad automated test, you don't want to stop and review the code. And so like you can almost become a bit of like a dopamine addict in a weird way here where it's just like I, it's such a high just building this stuff. And so it's like still just trying to be like, okay, even though you have these rules, you still have to stop, you still have to add automated tests. You still, to your point, have to make sure that you're following your own standards.

Awesome. Ben. I think it's a no brainer, but do you get people res, like not even knowing where to start? Like, I know cursor, you know cursor. Is this something people typically know already or do you have to say, all right, to get started, you use these tools, get started with this prompting. Like how do you recommend people get started?

I guess, yeah, a surprising number of people have still never even used cursor. But I think the biggest thing that I'm finding is obviously enterprise is going to be a little bit slow to adopt for the concern of security. Right. And I think AI in general, people are always a bit concerned of when it comes to security. I think that what I find interesting is like, if you are concerned about like using Copilot, for example, which is owned by GitHub, Copilot has very strong enterprise security policies. If you don't believe that they're going to follow those own terms of uses, then you shouldn't be putting your code in Copilot. So I'm a little bit frustrated at times because it feels like there's selective fear with some of these tools where it's like, okay, so if GitHub's willing to lie to you about how they're using your AI models, then you should never put any code in GitHub because then they're lying about everything. Right. Similar to Microsoft Cinema to all these tools. You know, Cursor is a startup, so I think that there's always a little Bit more on the enterprise now. I mean, it's billion dollar startup, but it's like. And I know they are pushing into enterprise, they have a lot of enterprise security, but there's a lot of hesitancy around the models and getting these through it sort of security clearances and stuff like that. So that's the thing I most hear is like, oh, I've played with it on a personal level, but I can't use it professionally because I'm limited. I think that six months ago I would have told you there's still some resistance at this point. I actually think I almost get no resistance anymore. I think the only resistance I hear sometimes is people saying like, oh, well, it's useful for other people, but not me. But like, you start to show them this and their eyes go, oh, wait a second, like, I get it now. So the primary blocker at this point is like, it security and people getting comfortable with the idea of AI and kind of, oh, is it secretly training against my code base and stuff like that?

Absolutely. So is there a light bulb moment you've seen? I don't know, like Jim and Butch. I think they all mentioned the page object. Is that like the wow factor that gets people or is there something else that you show as well that gets them juiced up?

So I cover page objects, I cover data factories. So like here you have a schema that's, you know, a couple thousand lines long and writing data factories is a huge headache. And like this thing can write data factories super, super fast. So I could pull in the schema and I could say, write me a data factory for contacts and it would create a factory with a bunch of methods for a seeding a contact with API endpoints. For one of the things that I try to show is like, I have spent so much time with poorly written swagger docs that don't give me the shape of the object that I need and so don't give me what requirements are already need to be in place to use an API endpoint. Not only can AI write much bigger swagger documents, I can just point AI at the endpoint back. Okay, tell me the shape of the object that this test needs. Tell me what dependencies are. And so from an information gathering perspective, that's where I feel like with Butch, I was like, hey. And that's where he kind of got it. So the thing that I find most interesting is people think when they get into my workshops that they're gonna see some like magic MCP thing, which is like fine and I don't really get into that too much. What I think that they're surprised on is, wait a second, I'm writing code and this can just write the exact same code that I would be writing a thousand times faster. And I think that people have a hard time pre my workshops maybe dissecting the different use cases and maybe this is just kind of clearing up, oh, the practical use cases, if that is clear at all.

Yep, absolutely. So actually we're only like four months away from 2026. I'm asking people this now because I, I do like trends every year. Is anything you see coming up in 2026 people need to be more aware of.

Yeah. So I think that what I'm most interested in is at some point whether or not we stop rating DOM based automation. So like for example, you can start to see this a little bit with Playwright already. Like Playwright has its mcp, which is like now interacting with the web without you having to write code to interact with the dom. And then you have basically you still a bunch of traditional playwright automation. What I'm going to be curious about is do automation suites in the next six months to a year to two years, do they start to just become natural, languish in many ways. Now they obviously have cucumber and gherkin and all these other frameworks. But what I'm talking about is basically that there's no longer a locator layer and instead you're just relying on AI to do what the human brain does, which is like, oh, I need to interact with this form. Downsides of that is like inherently it would be a lot slower. Like there's a lot of things about that that would be interesting. But that's probably the number one one that I'm interested in. The other that I'm more interested. There's a lot of people who are arguing somehow that there's going to be this, this slowdown period of how smart it gets. And I think there's a lot of software developers who are trying to use that as a reason to not adapt it. They're like, oh no, there's this evidence that it's not getting as smart each release or something like that. To me, as long as the context windows get bigger and bigger and bigger, it's going to continue to be more useful. This prompt could just look across the whole code base. Back When GPT dropped two and a half three years ago, you could do 500 characters. Gemini can now have a million characters. So what I'm going to be very curious about is like, how does its ability to absorb code before it makes a decision impact? Because the more code it can absorb, the better decision it's going to make. So those are the two trends I'd say I'm most interested in.

Absolutely. So when you say not dom, do you mean it's going to be image based on.

Yes, loosely. So my theory on that front is so like I don't know if you played with computer use for example at all, which is like through cloud. So basically it's just taking a series of snapshots very, very quickly, each action evaluating it based on the human, then going now the downside of that is it's very expensive and very slow. The upside of it is you can start writing tests in like seconds because there is no more DOM interaction, there's no more class and stuff like that. And so you're just like, hey, log into this app, do this thing. What I'm curious about is what the relationship between these two things are going to be. Because it's like if you can start to just run tests and it's stable, fast, easy and you're just giving it human based instructions and it's just interacting with the browser like a human would. There's also a lot of really interesting sort of acceptance criteria things there of like, hey, look at this page and like tell me what might be wrong with this page each step. Because for example, I just gave it a screenshot of a formatting error. I didn't give it any clue, I just said like, hey, what do you see that could be a bug on this page and it immediately identified the formatting error. So it's like there's things about the way that, that processes information that makes like assertions, for example so much easier because it's going to run, you know, hundreds of thousands of assertions every time it looks at an image like a human brain would. Right. So yeah, that's kind of the thought process. But right now, slow, expensive, so who knows where it's going to go.

Right.

And that's more like a real user. So if testers say, well that's the way test has always been saying they didn't like automation because it's not a real user. Well if it's using image based things then it's just like a real user because you're not interacting with the DOM that a real user wouldn't interact with. Right?

Yeah, 100%. And it goes back to like humans. I think we vastly underestimate how much capacity we as our brains can process. When we're looking at something like, it's stunning when you actually think about like, oh, I'm looking at this webpage, I'm analyzing so much. I remember when Image based first dropped for AI. I was sitting in an airport and I took an image. I told the AI, this is my golden screenshot of what that should look like. And then I took another image of the website. I changed one tag from critical to medium. And then I said, you know, I just finished test automation. What's the difference? Do you see any failures? And within seconds it told me, this tag on your golden was critical, this tag in your output was medium. So therefore something failed. And what's wild about that is that's exactly how the human brain would approach it if you were or I were writing test automation for that, we would have to write a thousand assertions for every possible little detail on that page. Right in that moment, like sitting in that airport was like, okay, whether it's tomorrow or a year or three years from now, how we do assertions within automation is going to fundamentally change along with how we actually write test automation.

Absolutely. And that's why I loved Appley Tools when they first came out. It was groundbreaking in 2015. And now I think that's becoming the norm for where the industry's going, for sure.

Yeah, exactly. And now you don't even really have to use like golden screenshots anymore because you can just ask AI, like, as a human, who's expecting this, and it's starting to get good enough opinionated where it's like, oh, yeah, like this is what I would expect. Or like, hey, do you see anything funky about this page? And it's going to tell you, fungi being a highly technical term.

Does this.

Work with legacy code or does it only work good with greenfield applications?

No, it works with legacy code for sure. The bigger the code base, the more you should put some context into it. And so, for example, let's assume it had a huge code base. The first thing that I would do is I would actually do this backwards. Rather than just starting off with something, I would ask it just to do research in the code base and find things. Because then once I'm telling it to do stuff, I'm going to make sure that I'm pulling in the four or five files that I think I want it to interact with as kind of the starting point. And so I'm giving it that context. So the bigger the code base, you just have to sort of think about the order of operations a little bit. More so on the like, make sure that you can give it the context for where you want to be in that code base and you're doing a little bit more research. That's really the only big difference.

Okay, Ben. And we could talk for hours, but 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 you or contact you or learn more about your business or maybe getting some of these one on one demos themselves?

Yeah, for sure. First thing on how to find me, check me out on LinkedIn is where I'm most active. Ben Fellows on LinkedIn. I also do some stuff on YouTube which you can check out a little bit more about my business. We basically do a lot of content, we do a lot of webinars. But ultimately if you want people that embed on your team that understand all this stuff, that's really what we are shining in. So we staff engineers on teams oftentimes for six months, but uptime sometimes up to three, four years. And basically what we focus on is providing a productivity boost alongside upskilling teams. And so what we're trying to do is kind of beachhead a lot of these initiatives within companies and then really bringing the existing QA teams on board and using it when it comes to kind of where to start and my most important things, I think that for better or worse, the best experience with AI is paid. And so I do think that if you're going to do this, you should set aside a couple hundred bucks as part of your experimentation. I know that's very hard for a lot of people. And so the best thing you could do is go to your bosses and say, hey, I want to download cursor, I want to do a premium model, I want to do a poc. And then I would just start with tedious tasks. What are the things that are most tedious, that are pattern based, that you can try to replace? And so that's where I would start. And that's why I always start with a page. Object models, database schemas, these things that are remarkably tedious, fairly pattern based. I pay for a premium model, I have cursor and it's made my life a lot easier. So that's where I would start.

Awesome. So definitely give Ben a follow. You can find links to all this awesomeness down below. Thanks again for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com a558 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 tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

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