EvilTester.com on EvilTester.com - Exploratory Testing, Automation, Development (Agile + Web)

Free Selenium WebDriver with Java Course Released To Youtube

Alan Richardson — Thu, 19 Feb 2026 09:00:00 UTC

TLDR; Selenium WebDriver Course course has been released to YouTube as a 16 hour video. And split into 8 smaller 1-4 hour video chunks

Free Selenium WebDriver Courses

Playlist and Resources

Course Page

course page

The course page has been updated to have the videos embedded, with some text description to make it easier to navigate.

I dropped some of the heavily deprecated content and re-organised it slightly when combining the videos.

Slides etc. can also be found via the course page

Other Free Online WebDriver Courses

I should also point out that in 2024, Rex Jones and FreeCodeCamp released a 7 Hour video course to YouTube showing WebDriver with Java, which could also be worth looking at for your self-education.

Rex Jones:

History of My Course

I first created the course for Selenium WebDriver 2, then updated it for Selenium WebDriver 3.

This was the first ‘big’ online course I created and it got a little too large.

Also it was fairly horrible to keep updating over time.

It would have been fine to update if it had only been on one hosting platform.

First it was on Udemy, but then they changed all their rules, controlled what you could charge, and changed their fee structure.

So then I moved to Teachable, but they backtracked on their promise to handle VAT properly (which they now do I think).

So then I moved to Zenler, and they then migrated to New Zenler, and then they completely abandoned the agreement that I was on for course hosting and basically turned off access to the course.

I tried to keep the course updated on all platforms at the same time because I had people subscribed to all the course sites. This made maintenance a tad hard, but forced me to automate, using the sites public and private APIs. I’m quite resourceful when it comes to automating.

Because of this, I did write code which could download the videos and create import routines and ‘mostly automated’ synchronisation tools for most of the sites. This made my life a little easier and meant that I could create the free to Patreon subscribers course hosting on testerhq.com

The data structures and code that backs testerhq makes it possible for me to now script the creation of longer combined videos through the use of some command line tooling and ffmpeg magic.

I’ve always tried to honour the ’lifetime access’ agreement, even when the course hosting providers haven’t.

Up until a month or so ago, I was able to create free coupons for people to migrate from NewZenler over to Udemy, but that no longer seems to work for my courses now.

So now… the easiest way for people on the different course hosting site to get access is directly on Youtube. And if you want access to the individual videos, people on Udemy should still have access. NewZenler folks have no access at all. I’m not sure about Teachable. But testerhq.com, which is available to anyone supporting me on Patreon has the individual videos.

The TesterHQ videos are hosted on Vimeo, so I nervously await changes to Vimeo due to the ownership change over to Bending Spoons.

Relevance

The course is a little old now because it is based on WebDriver 3. But there aren’t that many changes from WebDriver 3 to version 4 - some methods were removed, and the WebDriverWait now uses a Duration rather than int for milliseconds.

But… I did also keep the source code for the course up to date, and did update it for WebDriver 4.

github.com/eviltester/seleniumWebDriverAPICourse

The docs folder of the above repo contains:

the slides for the online course
handouts and slides for physical workshops based on the online course content

So… using the code in the repo, in combination with the videos, should still work.

If I get time then I might create a much tighter, more modern version of the course. But don’t hold your breath! I have other projects taking priority at the moment.

Thanks

Thanks to everyone who supported the course over the years.

People have asked for continued access to it, so there must be some value in going back and revisiting the material in the course.

You can find all the details and videos on the course page.

<p> <strong><a href="https://www.patreon.com/c/eviltester">Join our Patreon</a> from as little as $1 a month for early access to videos, ad-free videos, free e-books and courses, and lots of exclusive content.</strong> </p>

Software Testing Podcast - Agentic AI Quality Engineering - The Evil Tester Show Episode 030

Alan Richardson — Thu, 12 Feb 2026 09:00:00 UTC

This podcast episode is a chat with Dragan Spiridonov who created the Agentic QE fleet. Agentic AI for Quality Engineering. It can work with code, or websites. We will explore Agentic AI, what it means, and how to use it to improve your Software Development and Testing. Also introduce the Agentic QE Fleet and how it augments Claude Code and Claude Flow.

Agentic AI Quality Engineering

Dragan Spiridonov created the Agentic QE Fleet tooling:

This augments Claude Code to extend the Agentic processing to cover Quality Reviews and insights. The AI Tooling can use Playwright, Vibium and other Visual Automating tools to automate browsers and capture screenshots.

You can learn more about Dragan on his web sites:

For a more technical overview of the Agentic QE tool in action:

https://video.agentics.org/media/t/1_htfe35tu/370465892

Transcript

Alan Richardson: welcome to the Evil Tester Show, and in this episode we’re gonna be talking about agentic AI and software development. I am joined by a guest, the creator of the Agentic QE tool, Dragan Spiridonov

Alan Richardson: and you can find his blog, the Quality Forge at Forge Quality Dev.

Uh, so Hello Dragan.

Dragan Spiridonov: Hello, Alan. Nice to, be here as a guest to your podcast as I’m your, you know, fan for a long time.

Alan Richardson: Well, thanks for turning up. ‘cause I’m a fan of your stuff and it’s making me think and learn new things and that’s important. And you have a, an awful lot of websites, so I’m not going to read them all out. I’m just gonna link to them all in the show notes. but I think. Forge quality dev is easiest one to remember, and you just got your blog on it and you’re listing lots of experiments in there because what you’re doing with Agentic stuff is create a tool, but you’re also learning how Agentic stuff works and you’re learning in public and putting all this content out there.

Alan Richardson: I thought it might be worth starting if you gave a quick overview of yourself and your work.

Dragan Spiridonov: Quick one, that that will be hard. So in short, as it’s, we are now 2026, so yeah, I would say like 30 years in, it started as a computer service, technician, went into network administration, was teaching computer science in grammar high school and assistant professor at university, combining. You know, web development, web administration, database administration. In the end, somewhere like 12 or 13 years ago, I ended up in quality assurance world all the pieces and things I’ve been doing previous years just, clicked and I am been learning and. Building on the quality side for now, let’s say 13 years. Uh, for the last nine years, I helped, one startup build completely quality assurance and quality engineering, left that four months ago to start my own, consultancy. Now because, these things. Agentic related are, you know, I felt obligated as I’m learning about them to start sharing that more because, I’m noticing that not many people in industry are embracing this new wave that is coming

Alan Richardson: So, I mean, that’s hard because, ‘cause the agent is not the first thing you encounter when you’re doing ai. Right. We all start with the chat interfaces, chat, GBT, we do stuff. Uh, and I, I started with Claude Code in the chat system and created some applications and then essentially gave up on claude code because you can only do so much in there and it runs outta context and then stops building and then you have to move into the, the CLI.

So there’s a, a kinda natural progression through this. So did you work through that progression? Did you start on the chat systems then other code systems? Or did you just dive straight in with Claude?

Dragan Spiridonov: No, two years ago I started experimenting with a, prompt, so you know how I can prompt an agent. At that time, we only had chats to experiment with, so I would do like a tester, mindset.

I would give the same prompt to chat GPT, Gemini, or claude, and compare the results that I’m getting, a year ago. Or I would say maybe now more year and a half ago, I started diving deeper into really prompt engineering. So understanding how I can, make those general prompts more using like. Role based things, providing context markups, giving examples, so really going into prompt engineering. And that was still not enough because I would get like maybe 50, 60% of results that I could keep. So the next step. Next level was contact engineering. I would say a year ago I started diving more deeper into AI coding assistant tools like client root code that provide their own memory banks and give you like a first level for context engineering, where you are grounding your agents in a certain context of your project when you are, letting them run in your code base that improved the results. not, to get over 80% of the accepted results. sometime nine months ago I experienced agentic development and this approach and agentic engineering that’s like, next level after context engineering. And, you know, the results were mind blowing and now, you know, getting, I would say I can keep more than 90% of the things that agent produce,

Alan Richardson: So we should probably then explain what agent based AI is and how it differs then.

Dragan Spiridonov: yeah, so classical Chat GPT, LLM, approaches. That’s, you are only prompting LLM and there is, there is general behavior there of the l LMS as uh, like a standard transformers. So they will try to, find the best next word in, in the area and give you some answers. Agentic approach is. agents need first to observe the environment, so they need to collect the data about the, you know, let’s say you, you give them, some goal they need to achieve. They need to observe, collect the data that they need. They need to reason, so that’s the moment when either they’re calling the LLMs or they’re using the, some other mechanisms that some of the folks from Agentic Foundations are developing and I’m using like Reasoning Bank and some local specially developed models for specific purposes. And then they’re autonomously executing. towards the targeted goal. So that’s like you are giving the goal, but you are letting the agent do the all the work and heavy lifting and reach the goal. And you as a human in the loop, you are observing the results. And if you implement correctly, you can collect and implement your agents to do the. Their work ex in explainable way, so you can observe what what they’re doing while they’re doing

Alan Richardson: So that was an interesting description and because what you said was the agent, when it does reasoning, will call the LLM, which suggests that the agent can do things without calling an LLM where I’d always just assumed the agent is working as essentially a prompt into that LLM doing stuff.

Dragan Spiridonov: So agents have their own also their also programs. So they’re, pieces of software that they have their own logic. So you can code a lot of, deterministic logic into agent for types of tasks that you are certain that must be done in the deterministic way. But you call LLM only, when there is like a, new. , Crossroads. Or, point where they need to decide in which direction, you know, what would be the next step to execute to get to the desired goal?

Alan Richardson: So is the agent more than just the agents MD file or is that the agent? Because the agent’s MD file is readable. It’s uh, eng English language. So an LLM must have to read it to understand it, but you’ve got code embedded in there to let it do things.

Dragan Spiridonov: that’s not the agent.

Alan Richardson: Okay.

Dragan Spiridonov: only, agent definition that like claude or, codex or Germany will use to start a subtask using that, like a warmup prompt. And that’s, you know, if. Part of that call. So if in the MD agent definition you have a call to a platform, like in this case my agentic QE platform, it extends and it has additional capabilities on top of what is defined in the MD file.

Alan Richardson: Okay. Right. So the agent is kind of like a thread that starts up, it’s given some additional context. Some of the context you feed in through the agent’s file, some of it comes somewhere else, and you could essentially create specialized agents that do certain things that don’t even necessarily need to use LLMs, depending on the kind of orchestration framework that you have.

Alright, see, this is why, I wanted you. In here to explain this stuff properly. And from a, a kind of, this is just gonna be an overview of what we’re we’re covering. ‘cause you’ve done so many presentations on this, I’m gonna link to some of them. In the show notes so people can go down and through this, in more detail because I’m actually giving you a hard task.

‘cause I’m asking you to describe all this stuff in the work without any slides, without any IDE open. You’re not allowed to look at code, you’re just gonna have to verbalize it. So we’ll see how we get on. That’s interesting with the, the agents and you’ve pretty much built. The Agentic QE system on top of Claude at the moment.

So how would you describe the agentic QE system that you have built?

Dragan Spiridonov: it’s an quality oriented orchestration system with specialized agents and skills, like. Covering complete software development lifecycle quality related tasks. So whatever I was doing in the previous 13 or 14 years, like trying to become that calm shape person that, picked up different, specialties on the way the testing the requirements to. Creating test plans, test strategies, different generating test cases on different levels, analyzing the tests for flakiness, so, creating like a combo tool. For all the tasks that me as a tester previously needed to create separate tools. So, you know, you are also like a tool Smith, so I know you’re a colleague that creates his own tools to help him with the testing tasks. So we are using tools to surface the certain types of information and certain phases in the project as we are working on it. So my idea behind the whole fleet was to create. agentic based system that will provide tools I can use in different phases of the project and the product development to surface the information that I would be interested as a tester to identify faster risks to, maybe uncover things that I’m not specialist in, so I’m not. You know, I have a general knowledge of security testing, but I can make my agent, with induced with some practices that I not aware, and I can use that to surface some information that I would miss if I wouldn’t have a person of that specialization in my team.

Alan Richardson: Do you think that your, background, ‘cause when you described your background. It was, an evolution across the entire software development process where you’re, you’re doing development work, you’re doing networking, there’s very technical stuff. You’re teaching it. It’s not, it wasn’t just a I test things role, it was very much a software development role.

Then the testing on top of that showed you that quality aspect that’s required across the software development process. So your agent stack kinda reflects that. It’s not just a testing agent. That’s why this, the qe, the quality engineering aspect encompasses that whole thing. so what’s interesting about that is when you start creating agents that cover topics that you’re not an expert in, how do you evaluate them?

Like, how do you evaluate the security one? How do you evaluate the accessibility agent?

Dragan Spiridonov: I ask experts to evaluate that, so I’m asking other colleagues that I know that are in that field to check the results that these types of agents are producing and provide me feedback what should be improved. And I’m also not. Uh, I’m never satisfied with the first version that I get, so, I will always ask, you know, use, that’s why I develop certain skills I’m using now to evaluate the work of my agents while working on developing my agent fleet. So, I’m like doing a combo of agents and skills, reevaluating the results that they are, producing.

Alan Richardson: So since you’ve mentioned skills, what’s the difference between a skill and an agent?

Dragan Spiridonov: oh, this, this is like a metaphor that, I think people understand. Uh, easiest, everybody knows Matrix. Matrix, right? The movie. So you have Neo, you have Agent Smith, both them. A learned a skill just by, uploading it. So a skill is a knowledge of how you are doing some things. Agent is, let’s say object that executes that skill. So I know kung fu, but I need a physical, or in this case agent, I need like a body to execute the skill and, fight the kung fu with some other agent.

Alan Richardson: Okay. And are they pulled in dynamically when the agent needs them? If you tell agent use Skill X, then it’ll go in and pull it in.

Dragan Spiridonov: yes. And skills have

Alan Richardson: I.

Dragan Spiridonov: own related agents that they are calling because it’s not only skill is not like using only one agent. So for different, types of skills, you can use multiple agents in parallel on sequential or hierarchical, depending on the. , Context of the task again that you are trying to solve.

Alan Richardson: Okay, so since we’re doing this as an audio and we’re gonna start describing the agent QE fleet. So in order to use a agentic qe, you have to install Claude. Get claude working, then you do an NPM install minus G for the agentic QE fleet. Then that installs, something that you can run aqe to initialize information in your project, which then creates a set of, agents and other files in there.

Dragan Spiridonov: there,

Alan Richardson: And then you can start using

aqe on a project and you can do that within Claude and say, Claude, use the quality engineering fleet to. Do something. What kinda things would you use it to do on your project?

Dragan Spiridonov: Um. You can do it for different types of things, depending where your project is. So, let’s, you know, I, I will, for example, if your project is, is in a greenfield phase, so you’re starting with the requirements, you are generating some ideas you created maybe like a product requirements document or some documents that you want, you can use different agents to verify that.

So there is like a QE requirements validator. You can use, it’ll use INVEST and SMART criteria and other, good practices from the field to analyze the requirements to see really if they are, if we are missing something. And a lot of times it’ll find things that are missing. There is like. Lalitkumar Bhamare, he created QCSD version of skills that there is like a QC id, SD ideation form that the whole, heuristic base software testing model. Like, SFDPO or analytic analytics. So complete, heuristic based testing applied to the ideation or to the development or the refinement. So depending on which of the phases, there are different, swarm skills.

So they, he call them like, swarms, like, Q Cs, the ideation swarm or something like that. they’re, shift left testing skill if you are in the left. Like requirements analysis, feature analysis, and the things before we start implementation, we have skills for analyzing what’s happening. Okay, we need it now we have requirements. Let’s create a test strategy. Let’s create a test plan. Let’s define what will be the test charters that we want to, and that’s usually something that you get automatically if you use that QCSD, you know, a requirement or ideations form. It’ll create you suggestions, not only which test on integration or end-to-end level to implement, but which test sessions you should exploratory next to the automation that it provided.

Alan Richardson: Okay, so this, because earlier on you mentioned that the agent will go out

Dragan Spiridonov: out

Alan Richardson: and kind of find its context. So you could instantiate a QE in an existing project. It’ll have all the code. And you could then ask it to do things on the code, or you could instantiate a project in just a J any folder.

You could then start adding text files that describe what testing you’ve done, what you might want to do, how the architecture works, and it’ll use that. Or you could then say, A QE, here’s a website. Here’s a URL. Go away, have a look at it. Then it will go and fetch the content, pull it down, use that as the context, and then do stuff there.

Dragan Spiridonov: Yes. And we, there are visual agents, so there are MCPs and, let’s say, libraries, that agentic fleet. Agents and skills are using to go and really do the browser. uh, I’m using even Vibium for some stuff. So some of our visual testers have like a fallback If Vibium is not working because there is some problem on the Mac.

If the fallback to the agent browser, then as agent browser is already using like a Playwrite. Like an engine behind. If that is not available, it’ll just use the pure, pure Playwrite? And it run Chromium headless. It’ll capture screenshots, it’ll follow URLs. So whatever needed, it can do also from that side.

Alan Richardson: And do I have to install the kind of playwright MCP in Claude first? Or when I use a QE, does it dynamically bring down the MCP?

Dragan Spiridonov: dynamically, pull as a dependency based on my MPM package. The playwright, as a depend, it should pull playwright as a dependency, but is by some chance it’s not there. You can always ask claude. Okay? Please add, playwright, MCP and install Chromium. Run it in headless, mode. And when you set, set it up in your environment.

You are good to go.

Alan Richardson: Okay. So one of the interesting things about your website, the, quality Forge you have on there, I think it’s on the front page, a list of experiments. So it’s experiments that you’ve done, experiments you’re currently doing, experiments you’re gonna do. Then you blog about those experiments so we can see it.

you also have the, I can’t remember what it’s called, the Serbian Agent Foundation.

Dragan Spiridonov: There be an agentic foundation chapter in the time starting as ambassador.

Alan Richardson: Yep. And that’s all streamed on YouTube. And those videos are interesting to watch because you see the evolution of the tool and, you can see that it’s, you’re, you’re learning in public and experiment in public and. Some people might not like the videos ‘cause things are going wrong in the video. But I like that because then I can see it’s not just me.

there’s other stuff that we need to learn and then you see how to overcome it and you, you get the thinking process. ‘cause there’s a lot to learn in here. So this, do you view this as a finished product or a version product? Or is this an experiment that’s ongoing?

Dragan Spiridonov: Um. I mean, definitely a long way to be finished, but it’s quite useful currently, and I’m already getting a, a number of feedbacks from people using it on their products and getting value, especially from developers. So testers are you know, little, we are, skeptic by nature. I would, call it like that. And that’s okay. And as people are starting to use it. And experiment and see the results. I’m expecting them to provide the feedback because again, my experience is limited to my knowledge. I can build the. Fleet best based on my knowledge. But until I’m, and I’m getting, you know, there are contributors already, so Ali started contributing users as they’re using, when they, find problems, they will report a problem and I will, try to fix it, as my time allows. But I’m trying to allocate working daily on this project and keeping it live. it brings value in my other projects as I’m using that to test all other projects that I’m, working, using the agentic approach.

Alan Richardson: So it’s interesting that, I mean, I can understand why people who are more specialized in programming get more out of it than the, people in testing field. It’s partly because they’re the ones that are using these tools more like they’re using Claude much more. It’s part of their workflow. they don’t necessarily.

They haven’t studied security testing, accessibility testing, even to the limited extent that we might have done in

Dragan Spiridonov: in

Alan Richardson: just as part of testing. So the fact that something has a set of encoded information that they can use and it generates a human readable report, right? Because that’s one of the things when I’m using the agentic qe, I’m getting it to generate markdown, human readable reports.

It’s not. Doing stuff for me. It’s not like raising defects around this. It’s generating a report that I read and evaluate and then I can see the gaps in. And I had it running against one of my podcast transcription apps this morning. It was telling me in black and white, all the things I knew were wrong with this.

and I have to work on it. So when you’re using this, the agentic QE part is the.

Dragan Spiridonov: That

Alan Richardson: Quality information and evaluation. Does that mean that Claude, you’re using Claude as your development programming tool and then Agentic QE is a, an evaluation tool on top of that?

Dragan Spiridonov: them, but not only single, you know, not only claude. I am using, orchestration framework developed by founder of the agentics Foundation. And that helped, that really enabled me to get here. I use claude-flow for orchestration, so there is. claude-flow for orchestration, but not only, it’s like a planning research development, CICD, GitHub action.

So whatever, I need development related. There are a couple of testing agents there, but they’re not, they were not on the level that I wanted to have. That’s why I. Created and initially idea of Agentic QE fleet was like a extension for claude flow. So when I originally developed it, it was really tightly coupled with the claude flow.

You couldn’t even use it without the claude flow. And then, in the versions it, evolved into now, you know, standalone platform that can be used not only with the Claude, but any tool that has like, you can use with the MCP. Because my, agentic QA fleet provides MCP server. Any tool with the MCP client can access it. You can also access it through the CLI, so capabilities of the platform are not limited only to the claude code. Interface, but they provide the best results if you use the claude code interface because the subtasks system that they created and the prompts that Claude code pre prepares when he’s activating the agents or, calling the tools in the sequences, I, I need.

Alan Richardson: So that’s interesting ‘cause I didn’t realize that. So when I installed Agentic qe, I did see after the installation that said, now type with this claude install MCP. So I could have done that in any of the. CLI tools. I could be using that in Gemini. I could use that in open code as an MCP server, so I might try that.

That’s interesting. Because also at the moment, I am abusing Claude because I’ve got Claude pointed to open router. ‘cause you can now configure. I used to have to use the proxy, but now you can configure Claude to use that. So I’m using very different models in Claude than the Opus ones. So it’s running a little bit more slowly for me, but I can use this quite happily.

Dragan Spiridonov: on

Alan Richardson: On free models. Completely free models, so you don’t need a Claude plan for this. And, but that’s even more interesting that you’ve got the MCP server, so you could use that directly somewhere else. so, and also, so you’ve got Claude code for coding, then you’ve got Claude Flow for Development. So Claude Code gives you the ability to plan and then execute.

But Claude Flow gives you all this requirements analysis, everything.

Dragan Spiridonov: With the claude flow agents. So

Alan Richardson: Okay.

Dragan Spiridonov: approach, if you watch the videos, I’m using certain agents from the claude flow. There is research agent for a, doing the research. There is like a goal. Based agent, that creates me goal oriented action plan that I can use then to execute. There are, different agents and recently, like a domain driven design. Uh. Approach. You know, we introduced that, two months ago, and both the claude flow V three is rewritten using domain-driven design and heavily using now architecture decision records I’m now describing why some. Implementation decision was made and then that is keeping agents more on track to go much deeper and not, sidetracking while working on the task. So this is, again, one small trick. That significantly or Okay. Significantly. Again, when we are a above 90% significant increases from 90 to 95. So if you can, accept the results that you know from the, that you’re getting from the agents.

Alan Richardson: So you’re kind of hinting at this kinda memory system that’s in there. How does that, so one of the risks with a memory system for any kind of AI is that it learns the wrong things and, and so how do you avoid that?

Dragan Spiridonov: Oh, I have a number, I, I, I would need to go to, to list, all of them, but I have a lot of novel ways, to try to prevent that. So there is a couple of things built by, again, other genetic, foundation members. Roof created a tool called Mean Cut that will do and try to evaluate if some of them. are, really, going into real direction or not. So I, I, you know, I, I, I’m not even qualified enough to explain how some of these things work because, a lot of them are really like. Uh, PhD level mathematics or, academic level of, as new, new, research things that are being done in the, and as soon as something new in the mathematics pops up, guys are implementing a tool around that. So I’m having, now I, so let’s remember a couple of last things that I did. One was governance system. implemented completely governments system, that should uh, evaluation all of all skills we have in the system, and keep that evaluation against every model change that comes on the market.

And it has like a built-in evaluation that tests against three models to see if the change, if the change in the model, we change the skill behavior. Uh, expected results. So there is a lot of stuff, you know, I, I, I, sometimes I even need to find, you know, ask Claude, what do we have here? So I’m creating like a, a notebook, LMs from different versions. Of my repo because you can copy paste like a URL of GitHub repo. I give it like my, release notes page or something like that. And then I’m building like a notebook, LMs, so I can have like a history and ask, questions related to the things that we developed because it’s, it’s going really fast.

I cannot even track what, what we built, but there are things that I don’t think, yeah. Anybody is doing right now in the industry. And I have like one competitive analysis document. I will share you the link later. I did that, just to see, how Agentic QE fleet compares to, what exists currently in the market because

Alan Richardson: so I will be very interested in that competitive analysis, but since you’ve mentioned the competitive space, what I find it interesting, when I first heard about your work in the Agentic QE, I, in my head it was in the competitive space of testing tooling. And I don’t think it really is, it’s, an evaluation of the entire development process.

So what else would you be comparing it to?

Dragan Spiridonov: I can compare parts of the fleet vendors, and that’s usually when I see, when you see list, you know, I have this and they have only, each of them has, one box or two boxes or something like that.

You know, only parts of that because they’re covering different things and they’re focusing. I saw, most of the tools were focused on like, UI. You know, testing generation, not to count the tools that developers use that are checking code quality and on that unit integration level and there, but testers would focus their attention on the UI level, test generation, self-healing and things, and that’s wasted effort I would call it. So their information and, testing. Gold nuggets all over the project and the process that we are working on, and there are places where we can, make a bigger difference removing one of the bottlenecks than, working on creating better UI tests.

Alan Richardson: One of the benefits is, the Agentic QE fleet is open source so anyone can download it. just in case anyone wants to, I’ve had best results installing it on Mac, in fact, all the AI tools. I’ve had best results, install ’em on the Mac or can a virtual machine running Linux or a Linux machine. I’ve tried installing this stuff on Windows directly.

Some of it works. but when, like some of the coding tools work, when they start using tools, they all default into Bash. So you have to run it under the, the GitHub, CLI. But then when Node gets involved, some of the tools struggle because the Windows node installation is non-standard, doesn’t work as well.

I mean, you’ve mentioned that you’re trying to improve that on your tool to get it working more on a Windows system, so that’ll be interesting. But it’s open source so anyone can try it and it’s uh, free.

Dragan Spiridonov: Fork it and adapt it. So this is like my experience and in this case Lalit’s, because he was contributing a lot from his QCSD framework, combined, condensed into a fleet itself. But this is a showcase to show you what’s possible. You can fork it, you can build more specialized agents. My context is we are not doing this.

I got feedback from one user, but we are not doing this like that. Okay? use it. You have everything Engine is there. Modify the agent definition. to your context, modify domain definition to your context. So you can always ask Claude to modify to your context after forking it. you see contribution, something that everybody would, benefit from, you know, please create a PR back and let’s include that and let’s work as a community to make this tool, valuable to everybody. Who, wants to use it because I think will not give you 10 times, you know better, but it’ll give you some examples from which you can start, building and, , leveling up your knowledge. and experience and using in, in your process to, get results faster than, needing to sit and, code for, three hours and, and checking your flaky tests, run like, five times or something like that. So, yeah,

Alan Richardson: So, I mean. I would advise people not to do what I did when I first looked at the tool, which is download it and go, well, I don’t use Claude, so I’m gonna take all the agents and the skills. I’m just gonna plug them into, open code and experiment it and try it. That was an interesting experiment, but ultimately I didn’t know if it was working, it wasn’t working or not.

So I’d say try and get it working. Properly out the box, then go and review the agents that are in there. That’s an interesting experience. ‘cause you can see what’s codified in there. That actually got me thinking things like what would it take for me to codify my knowledge? What? What would an agent that does what I do look like and that, that’s an interesting thought experiment, an interesting thing I think, to try and practice and do.

So how would you recommend people go about learning? To use your tool.

Dragan Spiridonov: Uh, I would first direct them to you. You, you already mentioned, I think oh, not, you didn’t mention that URL, but you will share it. Agentid dash QE dot dev, it’s whole explanation of the agentic QE framework playbook, with the steps with the assessment. Where you are right now, you can do your, because it’s grounded in the classical quality engineering, you can assess your current maturity status to see how ready your processes are to go into agentic. So that’s like, if you want to, implement that in your company, in your team and processes, you can be guided there. But if you just want to experiment, take a look at the examples. There is a number of use cases. You can review the skills and then go into repo and find the skills definitions there. You know, you can even use this in the, claude code, but in the claude desktop or in the claude web. But instead of NPM install, ask Cloud, like run NPX Agentic dash QE at latest space in it. Space dash dash auto and it’ll install in the sandbox environment Agentic, QE fleet. And you can run it that. You know, first initial, just ask it, explaining what I can do with the Gent, QE fleet, and start experimenting with it.

Alan Richardson: I didn’t know you could do that. So can you do that on the free Claude plan as well?

Dragan Spiridonov: Uh. I don’t think you have the claude code available in the free plan. You need PRO license at

Alan Richardson: Okay. Because it’s just when you said, you mentioned you could do it on the web.

Dragan Spiridonov: but Claude code

Alan Richardson: Okay. Okay. Because Claude on the web will generate code, but that’s different from Claude code. Okay.

Dragan Spiridonov: like a,

Alan Richardson: I.

Dragan Spiridonov: a code. is just the chat, but slash code, you get the code, but you need to be pro or max account to get the, access, I think to the code

Alan Richardson: So, so one of the things, when I’m looking at the agentic QE thing, it’s, and the, the whole agent concept, it’s one of the, motivations for me looking at paid plans of things like claude. ‘cause I’ve been really avoiding trying to commit to a, a tool.

Dragan Spiridonov: I’m, you know, I need to jump in. I’m working, really making the fleet, vendor independent. So that’s, you know, I, and I see now, you know, claude can be used now with any. LLMs So you know, claude itself,

Alan Richardson: Yep.

Dragan Spiridonov: uh, Agentic QE Fleet already has capability. You can configure it to use open router to use other models.

There is configuration option. You can ask it to configure it to use other models. already used something that’s called Tiny Dancer that will. Allocate different complexity of tasks to different models. So it’ll not burn your cost if you’re even using to the API, not to the paid on accounts, but to the API, like, simple tasks will go to the haiku. Models then, medium complex tasks will go to sonnet and then, like a test strategy and some things will go to the Opus model. So it’ll already do automatically allocation of the task when the agents are being spun to different models

Alan Richardson: Because the Haiku models,

Dragan Spiridonov: Yeah.

Alan Richardson: yeah, the haiku models are certainly very affordable through an API,

Dragan Spiridonov: Yep.

Alan Richardson: the, sonnet and other ones are less so. and. I, ‘cause when I’m looking at the agents now, I would just imagine this is just gonna burn through my API credits. I’ve assigned it all to free models, but then I’m give, I’m working on code content.

I don’t really care so they can train their models on it Doesn’t matter to me. I.

Dragan Spiridonov: working on, on setting up a, OlLama, version. I cannot run everything on my Mac, so I’m, working on setting up cloud version where I will, have my own model. So that’s something that’s already there, but I need a model I can, have access to and I can connect it. And when I connect both cloud to that model and my fleet to that model, I’m vendor independent.

Alan Richardson: Yep.

Dragan Spiridonov: that’s, in the plan soon.

Alan Richardson: I, I feel kind of vendor independent at the moment. ‘cause I’ve, I, Claude code itself is pointing to other models and your, your tool is working absolutely fine in that instance. So we’ve covered how to learn, agentic QE tool. How would people go about learning agent based AI in general?

Dragan Spiridonov: Oh yeah. A a lot of places. But what are the good. So I’m suggesting, if you never experience anything in related to this, start with the basics. I watched like a Stanford CS 230, set of lectures from 2025, fall winter season. So that’s seven or eight videos are really giving. good explanation of all the concepts you need to understand about agentic development, will give you like a, good starting point to dive deeper into agentic engineering approaches promoted by agentic foundation. So we are preparing, We already have one-on-one. we are starting working on 2 0 1, 3 0 1, 4 0 1. So different courses are coming. There will be accreditation for agentic engineering role. That’s like a future role coming. And there are all, I would say all from adjunct foundation are sharing as they’re, learning in public.

So uh, like next to my. Agentic Serbian Foundation, YouTube channel. There are regular agentic foundation, events happening every Thursday and Friday. That’s like 6:00 PM Central European time. That’s like a noon Eastern European time, American Eastern time. so, links are shared usually on the LinkedIn. People can join there. Uh, there is videos.agentics.org. Website. That’s a collection of all the recordings of all the previous sessions from the webcast and Aker spaces from last, I would say year and a half of these Thursday and Friday meetups. So there is a lot. Of content. And a really interesting thing on that website, you have like a chat agent, you can ask questions.

For instance, how can I use claude flow and Q Fleet for software development or agentic development? And you will get like a slide deck, flashcards with the lessons and uh, links to videos you can access and look, deeper. Into the topics. So, you know,

Alan Richardson: I’ve started.

Dragan Spiridonov: yeah, you can, that those are like good starting points and then you will, follow people on LinkedIn that are sharing things and Yeah. You grow your network from there.

Alan Richardson: Yeah, so I’ve started going through the the video.agentics.org. And that summary system is necessary because the videos are not hosted on YouTube. ‘cause if they’re on YouTube, I would just take the link, post it into Notebook LM and do it that way. So, but again, it gives you more control over, over what is happening.

So one of the things you mentioned there is this is leading up to accreditation for a different role. How do you view the use of Agentic AI as changing your skillsets and your particular role?

Dragan Spiridonov: This is like, moving. Into a new role. I would call it like, I’m calling it for six months or more like orchestrator. So I needed like a mind shift change. I needed to, let go of some of the things and unlearn some of the things I’ve been learning for 20 years or plus. What helps me, that’s that critical mindset. , People say, but you will, you know, become dumber. But no, I’m just thinking on a different level. It’s a different level of abstraction. I don’t, you know, I, you know, are you looking at the code?

Yes. I’m looking. The code, meaning if I, see hard coded values or I see, something that’s not logically, you know, should be there just to, glance over it. But as the amount of code is, you know, code is becoming irrelevant. outputs, again, focus on the output. the code is doing what is expected, is it, you know. Developed by these quality characteristics that are important for our project is the performance. uh, below 200 milliseconds is the security SOC two or iso certified, So what are the things that I’m interested? I’m, need to let go of that code, and that’s something that heavily needed to lean on this. And to let agents do all the heavy lifting thing from there. And I need to do thinking, controlling, how I saying decisive, you know, the correction measures. when I notice that behavior that it’s, trying to go into that, that was happening more before. You know now with the guardrails and as agents are working and learning patterns, that’s also as you start using the Agent Q fleet, there is a whole memory system there where agents are learning patterns and self improving time and do a lot of things that in the end. most of the tasks that are observed as probabilistic because they need the LLM reasoning for them to make the decision in certain places in their, task execution. They will have patterns to recognize they can reuse, so they will become again, deterministic. But having, now covering them whole SDLC, I am feeling like I’m having superpowers. Yeah, but

Alan Richardson: I do know that feeling. Yep.

Dragan Spiridonov: okay. You know, step back. I’m still not there to make it fully autonomous. There are guys in the foundation doing everything without the human in the loop. They’re just doing the final verification when the app, okay, app is built, this is the new version, deploy to staging, let’s go and check. So they’re not even checking the git diff. And I’m still, you know, heavy on diffs.

Alan Richardson: I guess it’s, it depends on what kind of app you’re building and how you’re building it. It sounds as though when you’re using claude code with, Claude Flow, you’re getting a lot of unit tests in there at the same time, and potentially unit tests and requirement level, domain level tests, that gives you confidence so you can review those tests rather than necessarily reviewing all the code.

Dragan Spiridonov: code.

Alan Richardson: And then it depends, I guess, how much you care about the design patterns in the code as to whether you review the code for those design patterns either being met. But you also, in the QE fleet, it will tell you whether the code complexity is too high on certain classes, in which case you can say, go in and refactor this.

So you’re getting some prompts back from the QE fleet as to where you maybe should be concerned and direct some human reviews in the code. But it is interesting when you start using these tools. ‘cause when it’s a, a really small prototype, I don’t really review the code. I review does it work, and I go into test mode.

So I’ve gone into product mode to say, do this thing. Then I go into test mode. So all the skills that we’ve learned in the, the quality and testing process are really important. The skills that you learn at a more senior engineer level with a staff engineer. leading teams, those now are important because that’s what you’re doing with the, the coding tools.

Dragan Spiridonov: you know, team of agents and you need to coordinate them and give them context and assign a task clear enough way, so they are not lost in what they need to do. And that’s also a good thing that you pointed. I noticed that like, leadership, management skills are also important, critical thinking, communication, collaboration, and creativity. So, those are the skills that I see and that though they stay human related, so that that’s something that you cannot, automate away.

Alan Richardson: But having said that I did buy a SaaS. A couple of weeks ago that I refunded ‘cause I was absolutely sure they were vibe coding it ‘cause there were bugs. And I asked for a feature request. The feature request came in about an hour later and it’s like, there’s no way this has been tested properly. And then I started using it and it was buggy and I just, I’m not, I’m not using this thing.

So there are many people out there using these tools that do not have that attitude that you just mentioned or is clearly embodied in the agentic foundation yet. So when you’ve been building this tool, I’m conscious of time, but I want to try and squeeze in some extra lessons learned when you’ve been building the, the tool.

‘cause a lot of people might not jump into agentic AI yet, but there’s probably lessons there that they could take in any of the, the use of AI tooling that they’ve got. So what major lessons have you picked up from the use of AI tools?

Dragan Spiridonov: Yeah, spend your time to understand better prompt and context engineering. That’s, that’s like a ground base for, going step further. Because if you are not familiar of, what the good prompts looks like and what, how to set up a good context for your agents to ground them when they start working because, like. Each of the agents, the coding agents assistant, has their own grounding basic rules. So the Cloud MD agent, md, Germany, md. So in the root of each project, you go get like a basic grounding role, but don’t. Don’t try to put everything I, I notice, you know, people are doing, you know, mistakes. That was my mistake. And like your claude MD shouldn’t be more than 500 lines. Put links with helper files. If you have a need, you need to put the basic rules there. if you have a need of having more than 500 lines, because that, takes more context when claude is being loaded, so you can check the size of the context changing. As your claude MD files in is increasing, put the links and put helper files. That’s, that’s like a, basic thing to help people keep your claude MD clean and neat with, the provided like create something that’s, they go, also think anthropic just release, constitution give it Why So it, you know. Works better if it has something that you know, some people from Identity Foundation called North Star create your golden examples, golden documentation. So you have your own way of doing things. Use that, give that to agent and ask it now. Create me a prompt that I can repeat this every time, or create me a skill that will do this or create me agent that will do exactly this. But start from your experience and then use the agent to augment and amplify that because it’s like a, library on wheels so you can ask things. But again. It’s, again, at the end, again, critical thinking. So that’s why I have either brutal honesty review skill, or I have like, six thinking hats skill to observe the problem from different perspective, not only from one, trajectory.

So if you give like a, I have a devil’s advocate agent, but that’s like a single trajectory. So you know also what works like. Trust of brains. Ask a agent like act as a team of users. It changes the behavior so you know the small tricks from prompt and context engineering. And start experimenting in building and testing because un until you start, you know, feeling it in your fingers. You know, if, experiencing that mind shift change, you, you, yeah. That, that’s, you know, you need to, experience it in order to see how it can level your you know yourself to another level. Yeah.

Alan Richardson: Thank you. Yeah, I think that’s really important. That’s really important that people get to, it’s, the theory is useful, but the hands-on practical use is where you really. Get it. And also the theory can be really intimidating, right? Not everyone has a computer science background or has done the university degrees, but everyone has done the job.

And you can get hands on and use this. you can install it quite easily if you’ve got the right, Linux type setup and just start working with it. So, so that was a useful brain dump of knowledge. So now I think the hardest question is, so where is this going in the future? How the agentic ai, how’s it gonna impact testing and development?

Dragan Spiridonov: So, yeah, more and more autonomous. smaller models, specialized models or specific reasoning banks packed for specific tasks. What I’m seeing already guys from the Foundation are doing, they’re training small co models like, half a billion parameters, 1 billion parameters for specific tasks.

In for your tech stack. So that’s where I’m seeing, and when you have these specialized trained models or reasoning banks with the specialized agents, you’re again getting the deterministic behavior that most of us expect in the software development. But, done autonomously with agents.

Alan Richardson: All right. Well thanks very much, Dragan. so everyone can find you at Forge Quality Dev, and I will include a whole bunch of other links in the show notes here and I’ll try and include some of the other ones you’ve mentioned, but that was incredibly useful for me. I’m hoping it’ll be useful for everyone else.

But the key point is.

Dragan Spiridonov: is

Alan Richardson: get hands-on, experiment and have a look at the agentic qe, dot dev, try and use it, install it even at a very loose level, just on a website. You don’t even need the code base. Just see how you get on. Alright, thanks very much.

Dragan Spiridonov: Thank you, Alan for having me.

A Web Testing, Automating and Tooling Masterclass

Alan Richardson — Thu, 05 Feb 2026 08:30:00 UTC

TLDR; We can only test to the level supported by our Ability, and the degree to which we are supported by tooling to Observe, Interrogate and Manipulate the System.

Video

Watch on YouTube

00:00 Introduction
00:26 Application Under Test
02:51 Live Testing
03:41 Testing vs Automating
06:03 Testability vs Automatability
09:25 Workarounds
10:55 Technical Knowledge
15:44 Test Approach - JavaScript
17:02 Exercise - Test Approach
17:24 Automated Execution Approach
18:34 Exercise - Code Review
20:35 Exercise - Your Project
20:59 Server Side
24:20 Exercise - Test Approach - API
24:52 API Tooling
29:14 Exercise - API Testing
29:34 Automating the API
31:54 API Interacting with UI
37:09 End Notes

Introduction

A customer has reported that one of your pages doesn’t work. But your automated execution coverage tells you that it does. What went wrong?

That’s what we’re going to explore now.

difference between testing and automating,
testability vs automatability,
we’ll think about test coverage from a technology perspective,
and we’ll look at some tools that can help you test.

Here’s the Application Under Test.

https://testpages.eviltester.com/challenges/synchronization/infinite-scroll/

Infinite Scroll Challenge on the TestPages

Many sites have infinite scroll. You scroll to the bottom and it loads new items.

That functionality works. We have have automated coverage. That passes.

What’s the issue?

Oh yeah, sorry I forgot to mention. I’m going to encourage you to think. Ideally we would do this as a workshop, as hands on training, but it’s a video and text workbook.So all I can do is prompt you into thinking.

Contact me if you are interested in live training for your team or organization.

So what’s the issue?

Well, I can’t click the button. The page refreshes and scrolls too quickly and the button isn’t enabled for long enough when it is visible.

This happens with a lot of infinite scroll sites, there are footers that can’t be clicked, stuff at the bottom of the screen that you can’t see.

This did work at some point, because we tested it, but I guess someone changed the time out value and the automated execution assertions didn’t flag this as an issue.

So let’s start thinking about this from a Testing perspective.

Live

If this was a live project we could just stop here and raise a defect.

Obviously the timeout is wrong. Raise the defect. Move on to the next issue.

But wait.

We have automated coverage, and it didn’t highlight this issue.

We should think about the difference between Testing and Automating.

Testing vs Automating

Testing is what we do. As humans, we interact with the software and we observe, we build models, we learn, we compare the actual interaction with the models. We report information derived from the difference between our models and the observations.

When we investigate an issue and expand our models we interrogate the system more deeply to learn what’s going on.

Testing is the human activity of interacting, observing, thinking, learning, experimenting.
Automating, is the human activity of making the interaction and observation of the system an automated process. And that includes the comparing of observed results with the expected results.

Automating is a human activity which results in the output of an automated execution process. The only involvement with the human after the activity has been automated is to investigate the failure reports and maintain it when it fails.

So both Automating and Testing are human processes. But testing leads to more human processes, automating leads to an automated process that only involves humans when it fails.

NOTE: AI might change how I view the process of automating. Certainly I’ll need more distinctions in how I describe nuances around Automating, but for now, all the automating I do is Human Initiated, or Directed, and results in some automated execution process.

Testability vs Automatability

And let’s just quickly look at Testability and Automatability because these words are used badly when describing software.

Is this system testable?

Yes. I can access it in the browser, I can see it, I can interact with it. The button toggles too quickly but I can test the application.

But when we talk about testability we often talk about, adding ids to the elements, make it it more observable, etc.

Well the ids, are really for automatability, not testability.

In the browser, the browser tooling makes it observable because of the technology used, not the system.

Most of the time when we are talking about testability we are really talking about automatability.

This application has been built with automatability in mind.

It has ids, there are classes, the JavaScript source is visible, it is easy to change the state and configuration variables, this thing is so easy to automate and observe. But none of that was required to help me test it.

Testability is not the same as automatability. Keep that in mind as we continue through this process, particularly when we move to the server side interaction.

With the JavaScript Infinite Scroll system, the main thing that impacts my Testability, is the bug, preventing me from testing the button functionality.

Workarounds

Let’s quickly consider workarounds.

Your ability to find workarounds will impact your ability to test the system.

So your ability impacts the Testability.

Testability is as much about your ability to test the application as it is the application supporting you in testing it.

Depending on how deep you want to go. You can only test the application to the limit that you can observe, manipulate and interrogate the application.

Your ability to test the application is often impacted by the usability of the application, and that is true here. The application is not usable for one main function so it is hard to test that function.

But, we can work around that, for this application, with more Technical Knowledge.

Technical Knowledge

When working with the web, we need to understand our tool capabilities.

My tool at this point is the browser.

What can I do with it?

I can view the page source.

I need to be able to understand HTML. Some CSS. Some JavaScript.

Having the tooling ability to look at the source doesn’t help me unless I understand what I’m looking at.

So if you’re testing web applications, you probably want to understand:

How a browser works,
How HTML works,
What is CSS and how we use it,
What is JavaScript and how it works.

At the very least to have a reading ability of these technology artifacts.

So at this level, at the source, with the technical knowledge I have… I can see in the JavaScript some variables, I can see they are amendable.

But, I don’t have the tooling to amend it yet.

So, what else do I have available?

I can look at the dev tools.

I can see the DOM view shows me much the same as the source. But… it can be different.

The source is what we gave the browser to work with.
The DOM is what the browser created after interpreting and executing the source.

In the DOM I can see the JavaScript as well.

I also have the ability now, to interact and manipulate the JavaScript variables that I observed in the source.

There are a few timeout and millisecond variables there.

Perhaps the bug is the scrollAfterMillis variable?

Let me change that to 3000.

scrollAfterMillis

And… now it just takes longer to refresh, but I still can’t click the button.

Let me try the preLoadTimeout:

preLoadTimeout=2000

Now, the button stays active for 2 seconds before it loads the next set of data. That’s my workaround to make this application testable.

It also means that I can go a little deeper in the bug report and say that the root cause is the preLoadTimeout being too small a value so the user doesn’t have time to click the button.

You might be interested in this video and blog post covering more details of Chrome Dev Tools for Testing.

Test Approach

So what is my test approach for this?

load the page
scroll down
see that it refreshes and adds the data I expect
click the button
see that it doesn’t refresh when I scroll

Is that it?

Do I need to reload the page and check that it starts auto refreshing again?
How long do I need to wait after stopping it, and trying to scroll to make sure it doesn’t start auto-refreshing again?
What else?

Exercise - What is your test approach?

After this video I encourage you to think through what your Test Approach for this application would be.

Test Approach vs Automated Execution Approach

Once you’ve figure out how to test it, how would you automate it?

I’ll show you what we have here.

And this test passes.

@Test  
public void scrollToStopLoadingAndClick(){  
WebDriverWait(driver, Duration.ofSeconds(10)).until(  
        ExpectedConditions.elementToBeClickable(page.getStopLoadingButton()  
    ));  
 
    page.getStopLoadingButton().click();  
  
    new WebDriverWait(driver, Duration.ofSeconds(10)).until(  
        ExpectedConditions.textToBePresentInElement(  
            driver.findElement(By.id("statusMessage")),"Clicked")  
    );  
}

Is that good enough?

It works. It passes.

But it didn’t highlight the fact that the halting functionality is unusable for a human.

This is one of the issues when we automate something.

We automate the functionality.

We don’t automate the experience.

If you are interested in more details about WebDriver with Java then have a look at this video Masterclass on the basics of WebDriver with Java

Exercise - Critique the code

So after the video, or now, pause the video.

Critique this code:

Understand what it does
What does it not do?
- I can see it doesn’t try to re-scroll the page to make sure that clicking the button stopped the auto-scroll.
- What else does it not do?
- What conditions does it not check?
Should it match the user experience?
- How could it?
- What would you change to match the user experience?

Much automated execution coverage does not match the user experience. When it doesn’t then there is a risk that the automated execution passes, but the user experience doesn’t.

And there is a risk we don’t notice.

Testing will hopefully identify those issues. But automated execution often does not.

Exercise - Consider Your Project

Is there a risk on the projects you work with that the automated execution covers the functionality, but not the user experience of that functionality?

Server Side

OK, so that was the JavaScript version of the Infinite Scroll.

It offered us some scope for thinking like the tester.

But let’s push this a little further.

We also have the server side infinite scroll.

https://testpages.eviltester.com/challenges/synchronization/infinite-scroll/server-side/

It looks the same. It has the same bug, the button is too fast. And my automated execution passes.

But this page, when it needs new items to display it calls the server to get the information back.

Do you trust that statement?

How do you know it calls the server?

Visibly, in the browser, when I test it and observe the output. It looks the same.

We need to be able to be able to interact with the application from a technical perspective.

What if I just think it is connecting to the server, but I accidentally release the wrong version? What if I just renamed the file?

So we need to check.

We need to observe the application at multiple technical levels.

So let’s look in the dev tools again. And this time we’ll look in the network tab.

Filter by Fetch/XHR to see the requests made by JavaScript and I can observe a call to moreitems

Let’s interrogate that request

I can see a JSON response:

[
    {
        "id": 1,
        "text": "This is content item number 1. Scroll down
         to automatically load more content when the
          \"Click to Stop\" button becomes visible."
    },
    {
        "id": 2,
        "text": "This is content item number 2. Scroll down
         to automatically load more content when the
          \"Click to Stop\" button becomes visible."
    },
    ...
]

Great.

So I have tooling to increase my ability to test this.

But I need to know about:

HTTP Requests
Fetch and XML Http Request
JSON

My ability to test this application will be limited if I do not have that technical knowledge and if I do not know how to use the Dev tools network tab.

But at least I know now that it is making server requests.

I didn’t have to trust anyone. I could verify that this was true.

So now, our testing scope just expanded.

Exercise - Server Side Test Approach

Now, what do you have to test?

Is it good enough to just test the front end now but scrolling up and down and clicking the button?

After watching this video, take some time to think through what you want to test to cover the Server Side infinite scroll.

Do we also have to test that HTTP call?
How much do we have to test it?

Server Side Test Tooling

And… do you know how to do that?

How can you amend the HTTP requests?

We can do some of that from Chrome.

I could:

copy as cURL
copy as fetch

with cURL I can use the command line.

Or fetch I can amend it in the console.

I could take the cURL and paste it into an API tool.

I can do that in Bruno by creating a new request from cURL.

Or in postman I can paste in the cURL command into the new request.

I can experiment with it in these tools.

It is important to test the API on its own.

For example, when I built this, it was only when I was automating and testing the API, that I realised that I really need a limit on the count. If I let people make a request and ask for 6 million items back. That could easily bring down my server.

NOTE: you can find a list of API Tools on the API Challenges site.

Exercise - API Testing

As an exercise, think through what conditions you would want to test on the API, then you can use any of the tooling approaches mentioned to experiment.

Automating The API

I would probably want to automate the API as well.

This does remove us from the user experience because the responses from this API are normally handled by the UI, so just because we see something working in the API we can’t assume that it works with the API interacting with the UI.

I used RestAssured to automate the API.

The coverage runs at the same time as the web UI coverage.

And I have a lot more coverage at the API level, than I do at the UI level.

Think about what coverage you would add for the API.

Then try to automate it. I used Java, with RestAssured, but you could use any library or programming language you want.

Or you could even have a set of canned requests in Postman or Bruno or any of the other API tools.

For production API automating, I primarily use code and HTTP or API libraries. I don’t tend to use tools like Bruno or Postman.

But for production API Testing, I do use Bruno and other tools. Because I like the flexibility and the ability to see the requests being made.

Testing and Automating often sound like the same thing. But they have different aims and are supported by different tooling.

API Interacting with UI

And now I’m in the position where I’m testing the API in isolation of the UI.

Is that a risk?

For example, I don’t know how the front end handles a 500 error response. I can see it is the same JSON format but it is a different status code, does that make a difference?

[
    {
        "id"=0,
        "text"="For input string: '-1.02'"
    }
]

Would you test that?

Do you know how to test that?

One way to do that is to use a Proxy.

Intercept the request, amend it to be one that triggers an error and play it through to the front end.

And then I can see if the system handles error responses or not.

I would either use Zap or BurpSuite.

For this exercise I would use ZAP.

open a session using Edge
create a new context for testpages.eviltester.com
filter the history to “Show only URLs in Scope”
Set the breakpoint on all requests and responses
trigger a scroll through the UI
amend the request
see the result in the UI

I can use tooling to increase my ability to observe the system and manipulate the system at different technology levels.

NOTE: A list of recommended HTTP Proxy Tools is available on the API Challenges site

End Notes

It is often surprising how much depth we have to test and automate when testing even simple pieces of functionality.

The more that we extend our technical ability to cover the multiple levels of the application, and we learn how to use tooling to help us observe, interrogate and manipulate at those different technology levels, the more we can expand the coverage of our testing.

Automating is not the same as Testing. Both are human processes, but the output of automating is not the same as the output of testing.

But yes… we can be testing, as we are automating, we may well learn things during the process of automating the application. But we should not confuse the continued execution of the output from automating with testing.

Testing can miss things because we are human, or we may not have covered the conditions, or we may not have gone deep enough into the system.

Automated execution can miss things because we humans forgot to add the conditions, or we didn’t assert enough. But automated execution can also miss the human user experience and tell us things are working, when they clearly are not.

I hope that you do now go off and do the exercises yourself. You may not have all the skills to do this yet, you may not have tried all the tools. That just means you can revisit this exercise and application multiple times as you grow your knowledge and skill set. And repeat it when you want to evaluate or learn new tools.

That’s why I created the Test Pages, and that’s also why this is a fairly high level overview.

Remember to work through the exercises.

Exercises

The Applications Under Test

Exercise - What is your test approach for JavaScript Infinite Scroll?

think through what your Test Approach for the JavaScript Infinite Scroll application would be.
Do you need to reload the page and check that it starts auto refreshing again?
How long do you need to wait after stopping it, and trying to scroll to make sure it doesn’t start auto-refreshing again?
What else?
- what conditions would you cover?
- how would you approach the testing?

Exercise - Critique the code

Understand what it does
What does it not do? - I can see it doesn’t try to re-scroll the page to make sure that clicking the button stopped the auto-scroll. - What else does it not do? - What conditions does it not check?
Should it match the user experience? - How could it? - What would you change to match the user experience?

Critique this code:

public class InfiniteScrollTest {  
  
    static WebDriver driver;  
    static InfiniteScrollPage page;  
  
    @BeforeAll  
    static void setupWebDriver(){  
        driver = DriverFactory.getNew();  
        page = new InfiniteScrollPage(driver);  
    }  
  
    @BeforeEach  
    public void reload(){  
        page.open();  
    }  
  
    @Test  
    public void scrollToStopLoadingAndClick(){  
            ExpectedConditions.elementToBeClickable(page.getStopLoadingButton()  
        ));  
  
        page.getStopLoadingButton().click();  
  
        new WebDriverWait(driver, Duration.ofSeconds(10)).until(  
            ExpectedConditions.textToBePresentInElement(  
                driver.findElement(By.id("statusMessage")),"Clicked")  
        );  
    }  
  
    @AfterAll  
    public static void closeDriver(){  
        driver.close();  
    }  
  
}

Supporting Abstractions:

public class DriverFactory {  
    public static WebDriver getNew() {  
  
        WebDriver driver;  
        ChromeOptions options = new ChromeOptions();  
		options.addArguments("--disable-smooth-scrolling");   
        driver = new ChromeDriver(options);   
        return driver;  
    }  
}

public class InfiniteScrollPage {  
  
    private final WebDriver driver;  
  
    public InfiniteScrollPage(WebDriver driver) {  
        this.driver = driver;  
    }  
  
    public void open() {  
        String url = SiteConfig.SITE_DOMAIN +
         "/challenges/synchronization/infinite-scroll/";  
        driver.get(url);  
    }  
  
    public WebElement getStopLoadingButton() {  
        return driver.findElement(By.id("loadMoreBtn"));  
    }  
}

public class SiteConfig {  
  
    public static final String SITE_DOMAIN = "https://testpages.eviltester.com";  
   
}

Exercise - Consider Your Project

Is there a risk on the projects you work with, that the automated execution covers the functionality, but not the user experience of that functionality?

Because if that’s a risk, you might want to revisit your test approach and your automated execution approach.

How might your approach need to change?

Exercise - Server Side Test Approach

What do you have to test now that the Server Side calls are involved?

Is it good enough to just test the front end now but scrolling up and down and clicking the button?
Do we also have to test that HTTP call?
How much do we have to test it?

Exercise - API Testing

As an exercise, think through what conditions you would want to test on the API, then you can use any of the tooling approaches mentioned to experiment.

Suggested Tools:

Browser Dev Tools - fetch requests in console
Browser Dev Tools - generate cURL and use from CLI
Bruno
Postman

A List of API Tools is available on API Challenges site

Exercise - UI and API Interactive Testing

Use a Proxy to allow you to observe and interrogate the traffic from the Web Site to the Internal API backend.
Amend the Request to trigger an error response and see how the front end handles it.
Try testing the API from within the proxy.

A list of recommended HTTP Proxy Tools is available on the API Challenges site

How to Test This - Selenium WebDriver

Alan Richardson — Thu, 05 Feb 2026 08:00:00 UTC

In January 2026, I was guest on the “How to Test This?” Podcast.

Mamadou N’diaye invited me on his podcast to talk about Automating and other topics.

About This Post

All the notes below, and the transcript, are AI generated.

I feel it is only fair to release the summary like this because this is actually how I initially decide if a podcast episode is one that I will listen to.

I subscribe to over 80 podcasts and it is impossible to listen to that many, and do anything else. So I build a tool to do the heavy lifting, subscribing to the RSS feeds, transcribing and summarizing them. I look through the list of new podcasts and then based on the titles, descriptions, and summaries, I decide if I listen to the podcast.

Podcast RSS feeds don’t have standard way of saying if the episode has a transcript, or a location to download one from, so I have to transcribe it using local AI tooling.

I build my tooling using Python, but it would be perfectly possible to use n8n to automate this process.

I use this tooling to create the podcast episode summary documents that I release on Patreon.

Podcast: How To Test This?

Interview episodes where Mamadou N’diaye talks with with software testing experts.

Episode: How to Test with Selenium - Alan Richardson

Show Notes: https://podcasters.spotify.com/pod/show/spidey1944/episodes/How-to-Test-with-Selenium---Alan-Richardson-e3eh6ut
Download: https://anchor.fm/s/1060f2ec0/podcast/play/114907549/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-1-2%2F417304710-44100-2-6685d3c793c56.mp3
Published: 2026-02-02 12:37:08+00:00
Duration: 01:05:41
Host: Mamadou N’diaye

Video

Watch on YouTube

Audio

Overview

The podcast covers the development and application of Selenium and WebDriver in software testing, focusing on their role in improving test coverage and identifying potential failures through strong technical knowledge. It compares Selenium with more modern tools such as Playwright, noting that while Selenium is praised for its simplicity and consistency, Playwright offers additional features and a higher level of abstraction. The discussion also highlights frequent pitfalls in test automation, including attributing problems to the tools themselves, excessive automation beyond necessity, and insufficient communication between developers and testers. Practical advice includes implementing abstraction layers, prioritizing high-risk test cases, and avoiding overly technical, low-level APIs in test scripts.

The podcast further explores the importance of understanding application architecture, along with design patterns such as Page Object Model and Screenplay Pattern, which help in organizing and maintaining test code effectively. It encourages test automation professionals to learn programming languages like Java, JavaScript, or Python, practice in controlled environments, and develop a strong portfolio with clean and well-documented code. The role of AI in testing is also addressed, with the suggestion that it should be used as an aid for learning and support rather than a substitute for technical understanding. Ultimately, the episode promotes a balance between technical expertise and soft skills, advocating for close collaboration with developers and a commitment to continuous learning to keep up with the fast-changing landscape of software testing.

Briefing

Overview

This briefing summarizes key insights from a recent episode of the How to Test This podcast, which focuses on modern software testing practices. The episode features Alan Richardson, known as Evil Tester, who brings over 25 years of experience in software development and testing. Hosted by Mamadou, a seasoned quality insurance consultant with over 10 years of industry experience, the discussion explores Selenium, Playwright, automation practices, and the importance of technical knowledge for testers.

Key Takeaways

1. Introduction to the Podcast and Host

How to Test This aims to help software testers understand risk and adopt new testing solutions.
Host Mamadou is a quality insurance consultant with over 10 years of industry experience.

2. Alan Richardson The Guest

Alan Richardson is known online as “Evil Tester”, and has 25 years of experience in software development and testing.
Active in the community through platforms such as:
- EvilTester.com
- YouTube
- Patreon
- GitHub
- LinkedIn
Has authored notable books including:
- Java for Testers
- Selenium Simplified
- Dear Evil Tester

Episode Focus: Testing with Selenium

3. Alan’s Background and Journey

Began as a programmer and transitioned into testing via test consultancies.
Developed skills in test management, consultancy, and development.
Currently focuses on improving testing practices and educating others.

4. The Origin of the Name “Evil Tester”

Emphasizes the importance of exposing bad practices and risks early.
Believes in deep technical understanding to challenge flawed design choices and build technically proficient testers.

Mindset of a Tester vs. Developer

No fundamental difference in mindset between testers and developers multiple mindsets apply based on the role at a given time.
A professional software developer can perform coding, design, management, marketing, and testing depending on the project need.
Alan identifies as a developer who tests, highlighting the overlap, not the exclusivity, of roles.

Importance of Technical Knowledge for Testing

Understanding technology is essential for identifying failure points and injection points in systems.
Key technologies to understand include:
- HTML, JavaScript, HTTP
Technical knowledge allows testers to:
- Maximize impact
- Expand test coverage
- Test directly at the backend
Without this, testing may be limited to the front end, reducing overall effectiveness.

What is Selenium?

Selenium is a browser automation library with a consistent API across languages like Java, Python, and TypeScript.
Uses standard protocols like WebDriver.
Influenced WebDriver and bidirectional (BD) protocols, which are used in tools like Playwright.

Selenium vs. Playwright

Feature	Selenium WebDriver	Playwright
Type	Library	Framework
Capabilities	Lightweight, consistent	More built-in features, language-specific
Recommendation	Preferred for its simplicity and consistency	Offers more features but is language-specific
Use Case	UI testing, precise control	AI-driven automation, easier for beginners

Automation with AI Tools

Playwright is permissive, making it ideal for AI-assisted automation.
WebDriver is strict about element handling, which can make it more fragile in dynamic environments.
Automation tools like WebDriver are still viable for unit tests, but should ideally use abstraction layers.

Best Practices in Automation

Avoid using Thread.sleep() it leads to fragile and unreliable tests.
Use WebDrivers improved synchronization approaches (e.g., Duration instead of seconds).
Playwright abstracts synchronization, which makes it easier for new users, but understanding synchronization remains important.

Common Mistakes with WebDriver and Test Automation

Blaming the tool: Many issues are due to browser driver incompatibilities, not WebDriver itself.
Premature switching: Many users switch to Playwright or AI tools prematurely without fully mastering WebDriver.
Misunderstanding scope: WebDriver is not for API automation; it’s strictly for browser automation.

Test Automation Prioritization and Best Practices

Avoid over-automation not everything needs to be automated.
Automation should be a team effort not just the responsibility of testers or developers.
Use proper abstraction layers, not direct use of WebDriver in test scripts.
Avoid conditional statements like if-else in tests unless absolutely necessary.

Data Management in Testing

Data should be managed carefully to avoid test failures due to missing referential integrity.
Use data factories to generate test-specific, consistent data.
Best practice: Set up data either ahead of time or just before execution.
Important data should be obvious and directly specified in the test.

Collaboration with Developers

Encourages collaboration between testers and developers to avoid role isolation and silos.
Developers should update test code when they make changes to the application.
Build common ground by using similar tools and understanding the project.

Leveling Up as a Test Automation Engineer

Practice platforms like Test Pages and API Challenges are recommended for real-world experience.
Learn the language used in your job for maximum practical benefit.
AI tools can be used to consume information, critique code, and speed up learning.
Learn by doing, document your process, and embrace mistakes as learning opportunities.

Programming Language Recommendations

Language	Use Case
Java	Best for JVM environments, especially with Selenium
Python	Widely used, versatile, and easy to learn
TypeScript	Ideal with Playwright, good for web automation
JavaScript	Great for frontend automation and web testing

Portfolio Building Tips

Build your portfolio naturally during your learning journey.
Use GitHub to showcase your repositories.
Focus on clean, well-structured code with CI/CD, page objects, code coverage, and static analysis.
Keep projects private until they are polished enough to be shared publicly.

Final Advice and Call to Action

Emphasized the role of AI in the future of testing.
Encouraged continuous learning, technical and soft skills.
Final call to action:
- Learn by doing
- Document your process
- Never be afraid to make mistakes
- Share and reflect on your learning journey

Recommended Resources

Practice sites:
- Testpages.eviltester.com - https://testpages.eviltester.com/
- Apichallenges.eviltester.com - https://apichallenges.eviltester.com/
Tools:
- WebDriver
- Playwright
- AI-assisted code generators

Conclusion

The episode highlights the importance of technical knowledge, the evolution of automation tools, and the pressing need for collaboration, abstraction, and continuous learning in software testing. As AI and modern tools reshape the testing landscape, testers must adapt, deepen their understanding, and focus on quality, collaboration, and abstraction in their automation practices.

Final Notes

Here are the key insights and takeaways from the podcast text:

Understanding Risk and Testing

Risk-oriented approach: The podcast emphasizes the importance of understanding and managing risk in software testing.
Adoption of new testing solutions: It encourages testers to explore and adopt new testing solutions to improve efficiency and effectiveness.

Guest Introduction: Alan Richardson (“Evil Tester”)

Alan Richardson’s background: Alan is a seasoned software developer and tester with 25 years of experience.
Experience in testing: He has worked on various projects and has written several books on testing.
Activation on multiple platforms: Alan is active on multiple platforms, including EvilTester.com, YouTube, Patreon, GitHub, and LinkedIn.

Career Background and Transition

As a programmer, Alan started by focusing on systems design and programming: His background as a developer helped him transition into software testing.
Gained experience in test management: He has experience in test management, consultancy, and development.
Current focus: Alan now: focuses on improving testing practices, creating educational content, and helping testers understand software better.

Mistakes to Avoid in Testing

Avoiding premature tool switching: This can lead to frustration and decreased productivity.
Not understanding the technology: This can result in inefficient and unmaintainable tests.
Proper use of automation tools: Correctly using tools like WebDriver or Playwright is crucial for effective testing.

Learning and Development

Understand the underlying technology: Dissecting web automation tools like WebDriver and Playwright is essential for optimal use and test preparation.
Develop technical skills: Amplify testing skills and become a testers-programmer in your own right.
Acquire essential skills: Key skills involve HTML, JavaScript, HTTP, and CSS, which will help you to navigate the evolution of web applications.

Testing with Selenium

Selenium introduction: Selenium is a library used to automate web browsers, providing a consistent API across multiple programming languages.
Selenium importance: It has influenced and helped define standards for browser automation, such as the WebDriver protocol and the bidirectional (BD) protocol.
Common mistakes made by Selenium users: Avoid premature tool-switching, misunderstand the technology, and make proper use of automation tools.

Transcript

NOTE: auto-transcripts usually have a typos. I tend to skim read them, as an extra aid to decide if I listen to the podcast. But by the time I hit the transcript I’ve usually decided if I listen to the episode or not.

Hey everyone, welcome back to How to Test This, the podcast designed to help software testers understand risk and adopt new testing solutions with ease and confidence. Your host is Mamadou, a quality insurance consultant with over 10 years of experience across multiple industries. In each episode, he’ll talk to different experts and learn from them about how they test.

Welcome Alan Richardson. Alan Richardson is commonly known online as Evil Tester. He is an experienced IT professional with 25 years of experience in software development and testing. He is an independent consultant and coach helping teams improve their testing and automation approaches. A speaker at Confluence WorldWard and trainer with many technical web testing courses. of that, he’s an author of several books, helping testers, for example, Java for testers, Selenium Simplified, Dear Evil Tester, and many other books. He’s also a passionate content creator in this blog, EvilTester.com. He has blog posts, articles, tutorial, podcasts. He shares a weekly newsletter. He’s also very active on YouTube, Patreon, GitHub, LinkedIn.

So thank you very much, Alan, for being here and being open to share your experience.

No problem. Thanks for inviting me.

Okay. In this episode, we’ll be talking about testing with Selenium. First, we’ll start with Alan’s background and experience. Then we’ll discuss what is Selenium and why it could be important as a tester to learn. Next, we’ll talk about common mistakes Selenium users tend to make. After that, we’ll discuss some practical tips on how to make the most out of Selenium. To conclude, we’ll share recommendations to get started in your journey. If you’re interested in this tool or also getting a better, becoming a better tester. So without further ado, let’s get started. Thank you again, Alan, for being here. I wanted to know how did you got into testing? At what point did you decide to make a living out of it?

So that’s given I’ve been doing this for a long time. That’s a long story. So essentially I started as a programmer because I was very technical going through university. I went, I studied programming at university, computing, systems design, all that stuff. And my projects at university, I always wanted to be really technical. So I wrote a COBOL interpreter from scratch, which was bootstrapped by a design tool. So it was a GUI design tool that was generating everything. And I wrote a COBOL interpreter that sat inside a GUI design tool so that you could create Jackson structure programs and interpret them and trace them through. So then naturally I got a job as a programmer doing C and C++ for a company that was building GUI design tools. And then they went bankrupt. So I got a job at a test consultancy, helping them build test tools.

Then they went bankrupt. Then I got a job at another test consultancy. So then I had to start learning testing because I was building tools for them. But I was also at one site doing testing and testing was not something that you learned at university. So we’d learned system design, architecture, programming, but not testing. So it was really interesting for me at the start because I could use all the programming skills, all design skills, all the analysis skills. And I was learning testing skills. And at that point testing was for me a very technical process. Lots of programming. The tools were way too expensive. So you had to build your own tools. You were working with the development team. No one really, everyone was in flux. If you just use standard waterfall models, everyone went wrong. So you had to figure out how to do things in a more lean way. So just over time, I started to specialize more in software testing, but still doing programming on the side, then doing consultancy because I was a consultant, then contract testing, then moved into test management to control the process. Cause I was so annoyed with the way that people manage things. Then you start going to independence, you do consultancy and that means talking at conferences, training, blog posts, everything else. And then I’ve continued to stay in development. And over the last couple of years, I’ve mainly been doing development work. And now I’m back looking at the, how can we learn to test better and practice things better and create material and content for that. Yeah, exactly. Exactly. And you also known as Evil Tester. What’s the story behind this name? So it started because I was on a lot of projects that were really annoying and frustrating and testing wasn’t getting the respect it deserved. The development teams were not getting the respect they deserve. Everyone was split into silos. Testing was seen as this necessary evil where we were kind of holding things up because we were raising bugs because the development process was being constrained and no one was designing things. No one had the time to build it properly. So we were getting blamed for those things. And it gradually just got to the point where I was thinking, well, if you want, if you think we’re doing something bad and horrible and evil, I can show you what that means in your application and I can really hit it hard. So then I learned to really understand the technicalities of these applications and really raise risks and try and prevent these designs from happening before they even got through the design process to really hit it hard very early. And that was that whole concept for me of I will show you what it means to be evil to your application. And I will take the steps necessary and raise the risks and learn the tools. And you will not be able to bamboozle me in any shape or form because I will understand the technology. I will learn your programming language. I will know what we’re doing. I will look at the code. I will have it running locally. I will pull this thing apart. So that also helps bring me back into the development world from a testing perspective because you really need to know the technicalities if you’re doing programming. And I think knowing the technicalities really helps when you’re doing testing.

Yeah. But to me, I’m under the impression like you need two different mindsets to be a tester and also a developer. So do you consider yourself as a tester who automates or a developer who tests?

So I consider myself a developer who develops because I don’t believe that there are two different mindsets in the person. I believe there are two different, there are multiple mindsets that you apply for the role that you were doing at that time.

When you are programming, you are trying to create something and construct it and make it as well defined and elegant and working as you can. But then you have to step back from that and figure out where is it going to go wrong? How can I architect it so it doesn’t go wrong? How can I break it? If I don’t believe that you are one thing or the other. So I try to go meta to that. And for me, a software developer, a professional software developer can code. They can design.

They can do the management. They could do the marketing. They could sell it to people. They can test it. They can do performance testing, security testing, that whole set of things. And depending on what our focus is at that time, we build a mentality for doing that and a set of models that help us do the right thing at that time. So partly I believe that because I’ve done so much programming that I cannot believe that I can’t program. I have evidence that I can program. I have evidence that I can test. So I don’t believe it’s one thing or the other. And I’ve worked in product and I’ve worked in marketing. So I don’t believe that any of these are exclusive to each other. They have a lot of overlap and it’s just recognizing where that overlap is and what skills you need in order to be good at that role at that time.

Okay. And during your career, you’ve written many books about Selenium, Java. What problem did you see that motivates you to help testers become more technical?

So part of the problem is I don’t think people often understand the technology enough to see the risks that are there. So even, even when you’re programming something, you often don’t really know the technology. You know how to get the technology working.

But you don’t necessarily know the technology enough to pull it apart and see where the risks are. So we find those out in live. And testing when we’re looking at it, we don’t need to necessarily know the technology well enough to build it, but we need to know the technology well enough to know where can it go wrong and where are the injection points that I can take control of and where are the interface points that trouble can often creep in. And so if you’re testing a web application, if you don’t know HTML, you can’t look at the source code and understand it. If you don’t know JavaScript, you can’t look at the source code and see where it’s going wrong. You can’t experiment with front end. If you don’t know HTTP, you can’t look at the network traffic and understand how it’s communicating with the backend. So you don’t necessarily know where you should focus your attention. So if you don’t know any of the technology, you’re going to spend all the time on the front end.

You’re not going to be able to maximize your impact. If you understand the technology, you can say, well, I’ve done the front end for a while. Now I’m going to look at all the HTTP messages and that allows me with tooling to go a lot faster. I can expand the scope of what I’ve done, the coverage, and I can hit the backend very hard without having to go through the front end. And you can build a different model. So that’s why I think the technology is important.

Now let’s talk about Selenium for a complete beginner. Can you explain to us what Selenium is and what Selenium is not? So Selenium is a library that allows you to automate a browser. And that’s basically it. So if you use Selenium in TypeScript, you use Selenium in Python or use it in Java, you’ve pretty much got the same interface. So it’s a very standard tool.

Selenium uses standard protocols to talk to the browser. So it’s evolved over years and Selenium essentially set some of the standards for how tools interoperate with browsers now. So the whole Selenium team did so much hard work to create web standards for the WebDriver protocol and now the bi-directional protocol that is also used by Playwright.

Jason Huggins’ new tool Vibium is using the BD protocol and WebDriver can switch between the BD and the old protocol at the moment. So that’s still in evolution. But these are now standards that other tools can use. So they’ve done so much work to do that, but also Selenium is an abstraction so that we don’t necessarily need to know the protocol. The actual interface that we use when we’re writing code has not really been impacted by the underlying protocol changes, which means that you learn the API and it’s fairly consistent over years. They do tend to take things out that are slightly surprising, but then if you understand code, you can then go back and look at how they implemented it and then re-implement it yourself because it’s very often just the support abstractions that have been taken away. But basically it’s, for me, Selenium WebDriver is a library that we use to automate browsers and that’s it.

So in comparison to something like Playwright, Playwright is a framework and it’s different in the different languages. So you have more capabilities if you’re using Playwright from TypeScript than you do from Java. And in TypeScript is a whole framework where it will do your execution for you so you don’t need to have a test execution framework. Whereas if you’re using WebDriver in Java, you need to add something like JUnit because that’s your test execution framework. But in TypeScript, if you’re using Playwright, Playwright is your execution framework. So it does a lot more. And what I like about WebDriver is it is very constrained and focused on automating the browser. Because we’re in a world of AI now and there are MCP tools, model context, protocol tools for all of the different libraries. So you’ve got one for

WebDriver, which is fairly crude. Then you’ve got one for Chrome itself. Then you’ve got one for Playwright. And these are used by the AI tools for automating. So Playwright, because it’s very permissive with waits,, it can be used very easily for automating with AI. If you use something like WebDriver for automating with AI, it will be a lot harder.

Because WebDriver is much less permissive. With WebDriver, you find something on a page. WebDriver hooks onto that thing and says, this is it. And if the page changes and I lose touch with this and I will throw a stale element exception and you’ll have to fix it. Playwright doesn’t actually grab hold of anything. Playwright says, when you want me to work with something on the page, I will find it and I will find it each time I’m looking for it. So if it’s moved or it’s changed or we’ve refreshed the page, I don’t care. I’ll try and find it. Which in my mind makes it really useful for automating when you don’t want to take as much control over the process, but use WebDriver when you want to automate for testing. Like I like to automate for testing, which means when we’re, I’m going to keep talking. When we automate, very often when we’re testing, when we’re automating, we’re automating unit tests. People talk about, we’ve got the setup, then you’ve got the action, then you’ve got the comparison part. I can’t remember, people have different ways of explaining that. But with WebDriver, you would set things up, you would do your actions, then you would find all the elements that you want to do comparisons on, then do the assertions on those elements. If anything has changed when you start doing comparisons, your test will fail.

Right. You do the setup, you do your actions. And when you start doing assertions, you’re still using Playwright locators. So your assertions are also waiting for things to happen. So you’re still essentially allowing the page to change and evolve during your assertion process. So you can get away with a bad user experience when you’re automating with Playwright. It’s one of the risks.

With WebDriver, you don’t, because WebDriver will just fail, it will stop. And I like that. I like to have complete control over the setup and the comparison. And I want to know if something is not the way that I have modeled it. With Playwright, that is sometimes taken away and it makes it a lot easier to automate without having to fully understand the application. So, I mean, that’s why people seem to prefer Playwright now, because of the auto weights.

The concern I have is that people often, there’s nothing wrong with the auto weights, right? There’s nothing wrong with that. And it makes it nice and easy to do things, but it introduces risks into your process that WebDriver doesn’t. So hopefully everyone using Playwright understands the risks that these functionalities that make it easy to automate introduce into their automated execution. With WebDriver, you have to learn how the page and application works and pause for certain state conditions, then interoperate with the page, which can make it harder in the early days. But if you know how to do that in WebDriver, you’ll know how to do that in Playwright and you know how to do that in any other tool. But if you rely completely on Playwright with its auto weights, I think it will make you weaker longer term. But Playwright to me is something that’s been built for AI automating.

Rather than experienced automating in a tight constrained environment. So it really depends what kind of automated execution process people want. And for, let’s say you have a new tester coming to you and looking to learn a new tool. So what consideration would you take to guide him towards Selenium or Playwright based on his profile, the type of project, the context?

So it’s hard because if you’re working on a project, you’re there to get results and you get results within the confines of your experience. So if you’re new to automating, you’re going to pick the tool that makes it easiest for you to do the work. And at the moment, that’s going to be Playwright. Your main issue is going to be, you’re probably going to have to learn TypeScript in order to use Playwright effectively.

TypeScript is okay. It’s a little bit harder to set up than something like Java. Code completion is getting better. There’s a lot of asynchronous calls that can be a little bit hard to understand. So I don’t always know if people fully understand what is happening under the covers when they’re using TypeScript. With Java, it’s all very sequential and you can do async stuff if you need to, but out of the box, everyone’s going to wait, which in that sense makes it easy to program. So if you’re going to learn something, you have to focus on the results.

You want to achieve and then do experiments to get those results as quickly as possible. But if I was learning anything at the moment related to code, I would be using the AI tooling to help me. So, I mean, I use AI tooling a lot when I’m coding. Inside my IDE, I have a plugin called Continue, which allows me to do kind of code completion activities and ask questions in a chat.

About the code that I’m working with and generate code or from the command line, I’ll use something like open code with various models to generate code. And that allows you to get started very quickly because you could say in open code, create a project using WebDriver or using Playwright that will help me automate this URL and then say, here’s this particular page. I want you to create some tests.

And cover this and it will start writing code for you. You can then use that to make sure you understand where it’s written because you’re going to have to maintain it. But you’re getting examples that are contextual to your application. So it’s not like they’re just random application examples. They’re for your system. And if it stops working, you need to understand how it’s working. But I would try and take advantage of that.

I would take advantage of AI as much as possible because it’s scraped everything. It’s probably scraped my books and they’re in an AI somewhere. It’s scraped all the GitHub repos where we’ve all created examples on how to use WebDriver and Playwright and everything else. So it’s going to be pretty good at giving you basic code. And particularly if you’re doing web automating, you can use the AI to say specifically, take this URL, create a page object that uses WebDriver or Playwright and then create an example test that uses it. If you know the patterns for automating, you can get the AI to implement those patterns. So you don’t just get something like a recorder. If you’re using something like Playwright recorder or any of the recording tools, they’ll record, go to URL, click this horrible locator, click this, click this, do this thing, click this thing, do this thing. But it won’t build the concept of abstraction layers to make it easier to maintain. So you have to learn the right architecture for your test execution code in order to guide the AI. So there’s stuff you will have to learn, but you can also use AI to teach you. So ask the AI questions like, what are the best practices for WebDriver or for automating with Playwright or for doing this? And it will give you some answers that you can then go and research that you can experiment with.

If I was learning at the moment and because I’m still learning things, I use AI to help me do that. So I’m using AI all the time to learn new stuff. Okay. Thank you. And I also wanted to talk about your book. It was written like back in 2012. How has Selenium changed over time with all the new requirements such as web applications, CI/CD, DevOps, like how it has evolved for you? Is it still compatible?

So WebDriver hasn’t changed a lot. It changed enough that the code that you would have written back then isn’t fully compatible, but that’s only because they tightened up the API. So it used to be things like when you were creating a WebDriver wait, you would put in a number of seconds. Now you put in a duration, which is a standard Java class. So they tightened up the API and made it much better. So you can wait on durations of milliseconds or whatever else.

But again, if you encounter code that was written back then and said, I need to upgrade this to WebDriver for whatever the current version is, the AI can make a fairly good stab at that. You can understand what’s different. We’ve got so much code completion now that when you see it in the IDE, it will probably suggest how you can make it better. But WebDriver hasn’t changed so much at the API level.

It’s changed a lot under the covers. And now WebDriver is even easier. The complaints you often hear about WebDriver are, well, you have to download the drivers. You have to set up the browsers. You don’t have to do any of that anymore. You don’t even have to introduce a secondary package because they did create a secondary package that you had to install, but now that’s incorporated in the main WebDriver. So now if you say, create a new Chrome driver, it will go away, download the Chrome driver, download the browser for you.

And make it instantly accessible in the same way that Playwright does. So there’s a lot fewer barriers to entry. Okay. And back to your story, when you start adopting Syriam, was it easy for you or did you struggle? Was it easy? How was it when you started? So none of these things were easy at this start. I mean, the reason I wrote the book Java for Testers is I was trying to learn Java and the books were a nightmare.

I had no idea why I was doing anything because it would start with a couple of chapters of, now write this text file with these declarations in it. Now do this. Now run this command. And it didn’t work. And I had no idea how to fix it. The IDEs were not good enough. So I tried to work backwards and make it as simple as possible. But also at that time, WebDriver wasn’t WebDriver, it was Selenium. So it was Selenium RC, which was essentially injecting JavaScript into the page and using a very different API. It’s kind of like the way that Cypress operates, I think. Then WebDriver came along and that built a different API on top, but it was using a different communication mechanism. Then they standardized the communication mechanism. So you got the initial WebDriver protocol and it was using the DevTools protocol as well. Then you’ve got the BD protocol. So it’s become easier over time.

So when you’re injecting JavaScript, you can’t do things like, okay, now switch to this tab because you simply can’t. So there was a whole bunch of things we could not automate at that point. But then with WebDriver you could, so automating became easier. And the reason I learned it in depth so much was to make sure we didn’t introduce bad coding practices so that the worst thing you can ever do when you’re automating something is put in a sleep, like thread sleep.

Because that’s going to be so flaky and eventually you would just keep increasing it. WebDriver had a kind of implicit wait where it would wait for, it would do a kind of retry type mechanism. It’s a bit clumsy, but again, that would leave you open to vulnerabilities. So I’d learned how to wait really thoroughly by reading the code, learning HTML properly, learning how JavaScript works, knowing how to synchronize effectively.

So I created some content on how to do that because that to me was the core of how to make robust automating, learning how to wait effectively. So now Playwright has come along and it’s gone. You don’t need to learn that synchronization stuff anymore. We’ll cover that for you, which makes it easy to get started. But when things go wrong, you do have to understand that. And Playwright does let you step in and synchronize more effectively.

You don’t need to, and you probably shouldn’t start with that until you need it with Playwright, which is kind of the reverse of WebDriver. WebDriver, you really need to understand the application state and you really need to wait at specific times. Because the framework, the library won’t help you. But as an API, it hasn’t changed too much over the years.

So I imagine the mistakes are changing all the time. So the biggest mistake I think people make with WebDriver is they blame WebDriver when things are going wrong. And usually it’s not WebDriver’s fault.

The driver that’s supplied by the browser has introduced some incompatibilities. That happened recently with the Chrome driver. Then people don’t know that, well, if I go and look in the actual code of WebDriver on GitHub, someone will have raised an issue and the answer is probably there. So people are very supportive on that community. But generally people go WebDriver doesn’t work. Therefore, we must throw everything away and start again with a completely new framework like Playwright, which everyone is using.

Playwright uses TypeScript, so we’re not going to use Java anymore. So we’ll learn TypeScript and Playwright at the same time. So the biggest mistake people make is blaming the tool, not learning how to use it properly, then throwing it away and adopting a new tool when they didn’t fully understand why they were migrating. I haven’t really found a problem that I couldn’t solve with WebDriver, an effect of synchronization. And then I’ve been doing this for a long time.

But the mistake I think people is they don’t learn the tool in depth. And there’s actually a lot less to learn with WebDriver than there is with Playwright, because Playwright is a framework. So all you’ve got is a library. And also people then look at WebDriver and go, well, I’m doing API stuff as well. WebDriver doesn’t handle API. Therefore, WebDriver is not a good enough tool. And it’s like, no, no, WebDriver is a very specific tool to let you automate browsers.

If you want to then automate the API, you bring in a new library to help you automate the API. And then you build abstractions on top to help you. So WebDriver is kind of a tool that if you know how to program well and know how to architect your test execution code and know how to understand the web technologies, I think you can do well with it. But people very often don’t put the effort in to learn those technology aspects.

And you could argue that they don’t need to, so we should use an easier tool. And that’s great. Then use something like Playwright. And then you go, well, we need to use AI. Great. Start using Vibium or whatever other web tool you’ve got. But all of those are abstractions away from the technology and the act of automating. And so if you’re not learning how to automate effectively, at some point something’s going to go wrong and you’re not going to know how to fix it. So I still think it’s really important to get as low level as you can. And so I mean, it’s really useful even if you’re programming to try and learn some sort of assembly language or some sort of C++ or C where the guardrails are removed. And if you do something wrong, your machine crashes. It’s really important to go through that process. But most people don’t do that anymore. So I guess it’s kind of old fashioned. Experience the pain first so you know how to overcome anything.

Okay. And another common mistakes we tend to see is like new testers who get too good at test automation. They tend to want to automate everything. Do you think, how do you prioritize what needs to be automated or not? So I think, so that’s not just the tester’s fault. That’s a, that’s actually a process problem because very often what’s happening is we’ve split the team into people who write the code, people who test the application, people who write code to automate the application. So these people have to justify their roles and the people who write the code now don’t have to worry about automating it. So they don’t really have to worry about the scope. They will automate it, but they probably won’t use the same tools. So they’ll be using the JavaScript libraries to automate the JavaScript before it actually hits the browser.

Then you’ve got these test automators or SDETs or whatever the role is, whose entire job is to automate. So they’re going to automate as much as they can because that’s their job. Their job is not also to try and prioritize some testing or prioritize some development. Their job is to increase that expansion. So that’s what they do. So they would get too much automated execution. And because they’re not collaborating with the programmers, they’re not seeing what coverage has already been done by the programming team. So you get a lot of overlap. They may not be working as closely with the programmers, so they might not develop their programming skills as much. So they might be slightly weaker programmers and not know how to architect the code. If you have a process where everyone is working together and everyone understands the overlap, then the prioritization decision is made for the project, not the role. And then you can get a good overlap of coverage because people who are animating the SDET role can focus externally on the API or the UI, but they don’t have to go into extreme coverage steps because they know that there’s a lot of unit testing being done at all the different levels in the stack. And the people who are doing the testing can know what coverage is there at base level. So they can then go, right, we will rely on the CI going green for those barriers and we will just go really deep in these areas because we see risk in this section, which is really hard for these two people to automate. So we’ll hit this really hard. So it’s that. I think a lot of that is a process problem rather than a mistake that the people use. But also if they a lot of it, I guess also is I think people don’t know how to create abstractions properly. So they put too much in the test code rather than an abstraction layers. And so they spend a lot of their time maintaining what they’ve got.

And then they end up updating it, which is also a communication problem. If your locators are breaking when the new release comes in, it’s probably not. I mean, it might be because you did bad locators, but it’s because you didn’t know. And it’s because the people who changed the locators in the application didn’t also update the automated execution, which they probably should have done. So a lot of process issues seem like tooling or skill issues, but they can be solved by people communicating effectively.

Page object. So I still use page object models. Yeah. I mean, I think the issue with page object model is that people think of it as a page object when really it’s an object or components, which you can find on a page and some of it will be a page. Some of it will be a repeated section of HTML code.

It will be a react component that is being used. It’s about knowing how to abstract the application, but very often no one is taught these things. I mean, I mentioned earlier on that I started at university and we learned systems design, modeling, programming. We learned how to model things and create abstractions. People don’t know how to do that. Now there’s a book and it’s the domain driven design book is a very good modern overview of how to model an application and create abstractions. And if people learned that and applied it into software testing, essentially what you’ve got there is a, an application web domain. So you then have to model that with objects. If you’ve got an API, you model the API communication domain and you create objects for those. So it’s not so much.

That it’s page objects. It’s that we’re modeling the application in a way that allows us to automate it better. And that page object models are often mentioned that, well, we don’t need page object models anymore because we’ve got the screenplay pattern. Screenplay pattern uses actors and essentially functionality to do things, which is another way of modeling the world, right? But we’re not modeling the physical application at that point. We’re modeling the user.

But there’s no reason why the actions that the agent that you’ve modeled in the screenflow pattern can’t be using page objects because that action can involve using particular page object. So you can model the physical world in terms of page objects. Then you can model the functional use world as actors and screenflow. And then hopefully it’s a little bit easier to manage because there’s fewer actions and you update the page objects.

Page object when the physical application changes, that’s what these abstractions are for. They should only have to change when the thing they’re modeling changes, but otherwise they create an API that allows someone else to use it without worrying about those changes. So your tests should never really have to change very much because they’re using either actors with actions that can do things or page objects with methods that will make things happen.

But if the underlying page changes, you don’t change the test, you change the physical abstraction that it maps onto. Okay. So it seems like you need to have a very strong foundation. So for people who are starting in this journey to non selenium, so what paths would you recommend? Like, do you focus on WebDriver, IDE, coding? Well, so the first thing, if you’re, so it depends how fast you have to work.

Because if you’re learning it to improve your skills, you can take your time. You can experiment with WebDriver a little bit. You can make a mess. You can learn programming at the same time. And you can gradually improve. I mean, one of the reasons I created the test pages site, so testpages.evotest.com is a site that you can go to. It’s got all HTML controls laid out in different ways so that you can practice automating them.

It’s got standard applications so you can practice testing. And then you can experiment with different tools on the same application, very small chunks. So you can learn it and iterate over time. If you’re learning it for work, you’ve got this objective that you have to hit, which is we need to be automating something. We need this thing automated. So you’re going to have to just automate that as best you can and use AI to generate it if you have to, but then you work back backwards from, I’ve created this thing. Do I understand how it works? If not, I need to go and learn backwards, even to the level of, I don’t know what a class is in Java. Go and learn. You have to learn what it is because you’re going to have to figure out which bits are important, which bits are not, whether you need a constructor, whether you don’t. So you can work backwards. You can read other people’s code. That is one of the best ways to learn. Read other people’s code.

If it’s on GitHub, download the code, change it, see what breaks. This is how we used to learn in the olden days because you read lots of code because it was in magazines. Then you type some of it in, it would break. So you try and fix it. You can do that now. Lots of people create example code. Very often I’ll go and look at people’s GitHub repos and you don’t critique it and say this is wrong, but AI can do that.

Examples, you can get AI to go have a look at this code that I’ve just written. How could I make that better? Because you’re still a junior at this point, it can give you advice, but it’s fundamentally about experimenting and finding the right place to experiment. Automating Google is generally not a good way of experimenting because it changes too often. It’s not necessarily easy to automate, even though it looks simple, but using all the applications that are designed for that is the way to start.

So also on test pages, I have a list of other applications. So I’m trying to collect not just the stuff that I do or promote stuff that I do. There’s about 20 different other test applications listed there that you can use for practicing and use all of them, explore and experiment. I’ve got the same thing with the API challenges. So apichallenges.evotest.com, which is an API practice site. And again, that has a list of other APIs that you can use to practice because when we’re learning how to test, we can do whatever we want with the applications that we’re paid to test, but you shouldn’t be going away and testing Amazon or testing eBay or testing anyone else’s site. There are practice sites designed for that. They’re designed to gradually make it more complicated so you can actually learn because the real world is complicated and messy and it could be hard to learn in there because you very often you don’t know what’s going on.

But now we do have the advantage that AI can, we can use AI to help pinpoint what is going wrong, give me some potential solutions, try them out. They don’t work. You could ask a different AI system. I think it’s a lot easier now to work much, much faster than it ever was before. Okay. And is it also a good idea to integrate Selenium with the unique test engine from the get go? Yes. I mean, absolutely.

If you see examples of people using WebDriver or even Playwright from a main method, that’s wrong. Unless you’re building an application to automate something, that’s fundamentally wrong. What we want is a test execution framework like JUnit or TestNG. You could use Playwright if you’re using TypeScript or any of the other test execution frameworks. Because you’re working in the IDE, you’ve got that programming framework, you can refactor to abstraction layers, put your abstraction, depending on how you structure the project, you could put the abstraction layers in the main package or leave them in the test package. It really depends how you’re working. But absolutely. Because it’s really important to understand that when you’re learning to automate with a coding library, you are learning to code. There’s really no difference in using WebDriver.

As there is using an application that parses XML files. So it’s just another library with an API that does something on your behalf. Okay. And earlier you said flaky test doesn’t come necessarily from the tool, but mostly from the testers. So what does a good Selenium test look like to you? So if I looked in someone’s code and looked at the so if it was Java, I look in their test class, I look at a method that is annotated with that test, which will execute as a test. I’m expecting to see almost no WebDriver API in there. I’m expecting everything to be put into some sort of abstraction there. Because otherwise the test is not maintainable. So I’m expecting to see standard assertions, which are using either

J unit assertions or any of the other Java assertion libraries. And I’m expecting to see no if statements because generally we don’t have conditional work within tests. It is possible to write tests that do that. If you’re writing model-based tests, but most of the time we don’t. So chances are, if you’ve got an if statement in your test, you’ve probably, that should probably be an abstraction and you shouldn’t see that in your test or you should be writing data-driven tests that are controlling the data more effectively or setting up better. But the main thing I’m looking for is if I’m looking at a test for automate something, I probably shouldn’t necessarily know which library you’re using. Even if you’re using Playwright, I would expect most of it to be hidden behind an abstraction layer. I would expect to have to dive into the code a level below the test class to know what libraries you’re using.

How do you view data management? Because I know you also had a tool, created a tool to help generate this. What’s best practice for data management? So that’s an interesting question. Cause a lot of times when people look at stuff that I create, they go, well, you didn’t cover data management or how we set things up. It’s like, well, because that’s, isn’t that obvious? I mean, I thought we knew how to do it. Basically for data management, when you’re creating a test, you’re either setting up the data that you need beforehand. And it’s going to be in some before method or some test environment set up par and it’s going to be coded in there. Or the data that you’re using doesn’t matter because it’s just kind of filler. In which case it probably shouldn’t be specified in your test. It should be coming in from some factory. Like when we’re learning testing, we experienced the concept of boundary classes and a boundary class is really a set where it doesn’t matter which of these items I use. They should all achieve the same outcome. If we have a boundary class in our automating, we could just put the boundary class in as the value rather than a specific value. It shouldn’t really matter. So data management in test is about making the data that is important, obvious, and putting the data that is less important in a factory so that we don’t have to maintain all the time. So we only have one place to maintain it. So if I was automating something and we were creating a user, I would want a factory that creates the user object. Then in my test, I would want to specify, okay, I’m creating a user that has a name that’s too long. So then I would override the name to be 50 characters, but the rest of the data is unimportant. I don’t care what’s there and it’s coming from the factory, but it’s that 50 character name that is there. If it’s data management, if it’s data management for environments, then what’s hard is are we controlling the conditions that we want to test effectively? So sometimes we’ve done a lot of work with unit tests. We’ve created a whole bunch of automated execution, but we still want to play in live files to see how the system works because the system is still going wrong.

So data management is important. This is where it gets hard because you need data that has referential integrity. If you’re taking data from live and there’s a person’s address there, if there’s an address checking system in your environment, that address needs to be pre-populated in that address checking system to allow the flow to work. So it’s about referential integrity most of the time, making sure that if you’re creating a transaction, that the account already exists before you create the transaction, otherwise it will fail. So you have to understand the scope of what’s involved and then set the environment up either ahead of time or immediately before the test. Or if you decide this is too hard to manage, what you do is you take some of the data that’s there, but pull out of the environment data that matches the conditions that you want. So if you’re pre-populating your environment from live with data that has been partially anonymized, you may want a customer that has more than a thousand dollars in their bank account, but you find it hard to set that data in advance. You do a query in your environment to find a customer that has that, check all the conditions on there, then pull that back and use that in your test. But that’s slightly more advanced. Like most of the time it’s about control and it should be fairly small and isolate control because the test execution flow that we’re covering should be fairly small. Okay. Another question for you regarding working with developers. Do you have any advice on how we can work effectively with them versus working by myself, isolated in silo? Like how can we work together as a team? So the way we do that is by working together as a team.

It’s obvious that I think one of the things that I’m concerned about is that I think roles are one of the worst things that we can do to teams where people fit in their role. They only talk to other people in their role. They have little silos and we have teams, but teams are in different buildings because the programmers sit in this building and testers sit in this building. But again, how do you get on with most people?

Finding some common ground. And hopefully if you’re working on a project, part of the common ground is the project. But the more technical that you can, so the easy thing to do is to say, let’s put all the hard work on the tester, right? And the tester needs to become interested in programming so that they can talk to developers. They need to understand the technology a bit so that they can talk to the developers about the technology and understand what they’re saying.

There should be some give and take such that the developers know that they’re speaking to someone who potentially doesn’t understand the technology and can explain it. But sometimes you work on teams where that isn’t the case. In which case do the best you can to educate yourself so that you’re not talking from a base level of, I don’t understand the application. I don’t want to understand the application. I’m not prepared to learn anything technical about the application. Please tell me everything I need to know.

Elaborate. So that means everyone is learning a bit of everything else. One of the things I used to do is I used to, if I was on a project and I didn’t know the language that they were using, I would try and learn that language. And I would ask the programmers for help in how to learn that language. So if they were using TypeScript, I don’t know TypeScript, they’re using TypeScript. I’ll go and ask, what does this code do? How does this work? Can you help me with this? Or I’m looking at the code and I don’t understand it. Can you help me understand it? That’s their area of domain knowledge. So they can explain it and they’re probably more likely to want to explain it to someone that is making an effort to try and learn. So the main thing is to try and break down the barriers and not let the role get in the way. View them as peers on the team. They’re not better than you. They’re not worse than you. They’re not stupid because they code in mistakes. They have the same time pressures that you do. So educate them in what you do and how you do it. Learn what they do. Try and pair in both ways. Pair so that you can see the unit testing that they’re doing in the coding. Have them pair with you so that they can see the testing that you do. They can see how hard it is to automate if they haven’t put the right data IDs on the front end. Like shared pain is a really good way to collaborate.

And build bridges. Got it. So now that we know what mistakes to avoid and what best practice to adopt, let’s talk about what to do to level up. Do you have any resources, books, websites you recommend for a test automation engineer who wants to level up? So all the practice sites are there to help practice. So API challenges has a list of exercises. It’s designed so that if you can do all those challenges in the API challenges, then you probably know how to understand and test APIs. If you could automate everything in test pages, you probably know how to automate. So it’s about go through, test these things, experiment with them. And if you spot something that you can’t do, that’s a gap that we have to learn. Initially use AI, do web searches, do blogs. I mean, I have a huge number of

YouTube subscriptions and channels that I look at and monitor. I have about, I mean, I had to write tools to help me consume so much information. So I have a podcast subscriber that I’ve written that subscribes to about 80 to a hundred podcasts, downloads them, transcribes them, summarizes them. So I can read the transcript and the summary to go through it quickly. And there are other tools out there that you can use. NotebookLM is really good. So if you subscribe to a whole bunch of channels on YouTube, instead of watching the video, take the video link, paste it into NotebookLM. NotebookLM will pull the transcript back. You can then ask it questions, get summaries. Then you can go and watch the video if it seems something that’s useful. So try to do it smart, because we’re in the age of AI now. Use the AI tooling to 10X your productivity as much as possible. It’s no longer about buying a book, working through that book, for a year and coming out an expert at the end. It’s about incrementally moving forward, taking all the little questions and gap areas, multitasking your learning process to build a model and filling it in as you’re going through. So it really just depends on how much time people have got and the objectives they’re trying to achieve.

So today I was working in Python and Java. So I’ve got an application that’s using a lot of AI stuff. It’s in Python. Another one that’s written in Java. I quite like Kotlin. So it really depends if you’re working. So the best application to learn, the best programming language to learn is the one that’s being used in your work. That’s absolutely the best, because then you have code that you can look at that is live in production.

And the libraries that are there, you’ve got experts who can help teach you. And the next best language to learn is the one that you see in Java for jobs that you want to do. So then you learn that one, because that might help you get a job or a different job. But then you experiment and you put things on GitHub and you either create your own applications or you automate the existing practice applications.

So I like things about all the languages and dislike things about all the languages. But I think the main ones to learn at the moment would be a JVM based language, like either Java or Kotlin, a JavaScript language, so either TypeScript or JavaScript, and then a more loose language like Python, possibly Ruby, but it depends on your environment. But you can’t really go wrong with Python.

At the moment, because it’s AI based, but I don’t think people use it for automating very much. Whereas I think TypeScript and Java, possibly C# are probably the main automating languages. But then you’ve got some people going, no, no, we use Python. We use the Python bindings for this. So it really depends. I don’t think you can go wrong with TypeScript and Java at the moment. Okay. And for people looking for jobs, for example, do you recommend them building a portfolio?

And what would you put in it if so? So I would build a portfolio and then I would build a portfolio naturally because I’m learning stuff and my portfolio is the results of me having learned something. So at the minimum I would have a GitHub account with some GitHub repos. The issue you always have with a portfolio is you want it to make it look good.

You don’t want it to make you look bad, but the issue you have when you’re creating a portfolio is you probably create it when you know the least. So anyone whose experience is going to look at it and it’s going to make you look bad. So if you’re doing an automation project as part of your portfolio, you shouldn’t just leave it as, well, it passes, it automates, it works. You need to then push it a little bit further on GitHub, put it into GitHub actions so that it’s running as part of a

CI/CD process. You want to look at it and go, well, I’ve heard about these things called page objects. Can I use page objects? Try and use them in your project. I’ve heard about ScreenFlow Power. Can I use it in your project? Get AI to critique your work. Use the static analysis tools, build them into your process, like use linters and use code coverage to make sure you’ve got unit tests and things that are there. You want that to be a good development process. It can be small. It could be really small.

It can only automate a couple of small examples, as long as it’s really tight, really good code. If you’re learning something and you’ve got some good portfolio examples, make the stuff you’re learning private until it’s good enough to be public. So it really depends how comfortable you are learning in public. I mean, I have stuff, I do have private repos, but it’s because there are potentially things I might try and commercialize, but otherwise most of the stuff is public. I mean, I write, I put out videos of me making mistakes and not knowing stuff because I’m learning. And I think it’s really important that people see that everyone struggles when they’re learning and that we make mistakes. If you only ever see polished content, then you think you’re stupid because you’re making mistakes, but these people never make any mistakes online. But they’ve all made mistakes as they’re learning. It’s just they might not have learned in public.

So it’s almost best not to put out, I really believe this, but instead put out, I experimented with this and I achieved this and I learned this and do it as kind of scientific observation as possible. But also that’s what we learned in testers when we’re writing defect reports, because then we get less pushback. So all the skills that you’ve learned in your job use that in your communication.

When you’re trying to get another job. Okay. And beyond what’s technical, what other skills should testers focus on? So anything that helps them, I mean, in the back here, this chunk here is filled with Chinese strategic warfare philosophy. Like, so they are of war, martial techniques, book of five rings, things like that, because strategy is really important. We have to learn how to think in projects to know how best to tackle things. So I learned that from like old Chinese philosophy and up here are kind of modern strategy books, but also down here and down here are books on psychology and communication, because that is something that we have to do as well. Not just in terms of how we communicate with people, but every application that we work with is a codified result of people communicating to each other. Therefore it’s going to be filled with misunderstandings, ambiguities, miscommunications. And a lot of time that’s what we do in the testing role is to find those miscommunications that have been encoded in the application. If we don’t know what the miscommunications are in the first place, it’s much harder to look for. So psychology is a useful thing to learn. So I try and learn practical psychology by looking at brief therapy type processes and hypnosis. Other people like to look at sociology because they like the kind of group dynamics and the kind of metal models of how people think. So it’s really what you’re naturally inclined towards. Like even if you were inclined towards physics or chemistry, or biology, that concept of how do you build an effective experiment is really important because that’s what we do when we’re testing. So try and find your natural inclinations and map them onto testing. It’s a little bit harder to map things like guitar playing and drums, but there will be things that you could impose on there if you were an expert guitarist or drummer.

So last question for you today. How do you see the future of testing and what will be your final advice for aspiring testers? So the future testing is interesting because it really, at the moment, the thing that’s shaken up the world is AI. When you do a lot of coding using AI, you find yourself in the position of a tester and a reviewer naturally. So the more that I’m coding with AI,

I’m not so much the coder anymore. I’m the person that is coming up with the requirements, the acceptance criteria. I’m checking whether it works. I’m hinting, here’s the bug. Please go and fix it. So those skills that I’ve developed in testing are now really helpful for me coding with AI. And so that’s a natural extension. But if you’re coding with AI, you need to understand the underlying technology and the programming. Otherwise you can’t fix it when it goes wrong.

And you can’t review it. So I think I still believe that the the gamma of software development skills is important, but you don’t have to learn them all at once, right? You can pick and choose today. I’ll learn a bit of project management today. I’ll do some testing. I’ll learn some security testing. I’ll learn this technology bits and pieces, bring it together. So I guess the best thing to say is don’t be so narrowed in on your role.

That that’s all you learn. If you’re a tester, don’t exclude programming because you don’t think that’s part of the role. Don’t exclude management or product. Take an interest in all these parts to whatever level and try and become a well-rounded software professional.

Cool. Thank you. Well, good to speak to you. You’re welcome. So thank you. So that concludes today’s episode. I hope you find today’s episode valuable. If you did, please share it with your colleagues and stay tuned for upcoming episodes. We will continue to learn from experts about their favorite testing tools and tips to become better software testers. So I am Mamadou, and this was how to test this. Thank you again and see you next time. Bye. Bye bye.

Test Interaction with HTML form fields

Alan Richardson — Thu, 15 Jan 2026 09:00:00 UTC

TLDR; When testing web apps we need to test the interaction between the browser implemented controls and our system. We don’t test the browser.

Testing HTML Form Fields

Watch on YouTube

Testing Web Technology

I like to use the term Technical Testing.

Many people don’t. I think other people view the term as implying that some people are technical and other people are not.

I use the term to cover “Testing which is informed by Technical knowledge”.

So if you’re testing a web application, you need to understand web technology, you need technical understanding of how browsers and the web works, otherwise you can’t test it effectively.

In this video I try to explore some of the reasons why this is important.

If I’m testing a web application and it has a form, and in the form is a date field which has a date control calendar pop up which lets me set a date.

What should I test?

Should I test that…

the calendar popup works on mobile and every web browser?
the calendar control works with keyboard?
the calendar control correctly switches years and months when I click the control buttons?

Well, no. Not if the HTML looks like this:

<input id="datetime-local-input" 
 type="datetime-local" name="datetime-local">

All of the complex UI interaction is implemented by the browser.

All our application does is use an off-the-shelf browser provided control.

Do I not test the functionality?

When we are using off-the-shelf controls like this we have to test the interaction between the control and our application.

If we added JavaScript event listeners to the control to perform extra validation or functionality then… yes we have to test that.

If we use the date entered in the control by the user, then we have to test that our application can handle the data supplied by the value of that control.

If we are not using the date then we should question why we have the control on our application UI.

Learn to spot technology risks

I can see from the HTML above that there might be an accessibility risk, because I don’t see any ARIA attributes associated with that control.

So we might not have configured the control in the page properly to implement all the accessibility requirements we might want.

If we had created a custom control, or it is specialised React control, then we do want to test it because we just introduced a technology risk that might impact mobile and different browsers. We might also have functional bugs.

But if we are using built in browser controls we don’t need to test as much functionality related to the control. We need to test the functional interaction with our application and custom code.

Test the Domain Configuration

We shouldn’t spend a long time testing validation messages from custom controls, but if a control has been configured then we need to test that the configuration is correct.

<input id="password-input" type="password" name="password"
 pattern="^[A-Za-z0-9_]{4,12}$" maxlength="14" required="true">

I don’t need to test that the password control above shows dots instead of letters and hides the input. But I do need to check that the configuration we supplied for the validation pattern and length are correct. And I need to make sure that the password is actually required (because we configured that it is).

NOTE: eagle-eyed readers, who have a technical understanding of how the configuration works will probably have spotted a bug in the above configuration. Yes. We should find that bug in our testing. And we know to look for it because we understand that the control has been configured with our application domain rules, and that’s what we are testing.

Don’t Trust the Client

The greater the technical understanding we have of the web technology, the less we will trust any data that the server receives.

We can edit the DOM to bypass domain configuration.

We can use JavaScript to enter data that bypasses browser validation.

We can bypass the browser altogether and just communicate directly with the server.

A greater technical understanding allows us to understand the risks of the technology more effectively

Testing Web Apps

All of the examples above are from:

testpages.eviltester.com

I also have a guide to testing HTML elements to describe some of the risks and issues that we might have when using or configuring off-the-shelf HTML fields and elements.

Testing Input Elements - Notes and Exercises

I had to learn web technologies when testing web applications.

I have seen people functionally test the browser implemented controls because they didn’t learn web technologies.

This means they wasted time, because they didn’t understand the technology they were testing.

New Version of CounterString Extension

Alan Richardson — Sun, 04 Jan 2026 09:00:00 UTC

TLDR; Generate CounterStrings, random data from Regex, ranges of data, and strings made by concatenating repeated data.

I released a new version of my CounterString generation Chrome Extension with new features and a new UI.

CounterString Extension

Watch on YouTube

Source and Download Links

I have a tool page for the CounterString extension with more details.

https://www.eviltester.com/page/tools/counterstringjs/

But you can find the tool:

Overview

I first released the CounterString Extension in 2019 (I think), and at that point it was a simple input field that created a string and added it as a value to the input field.

Now it can:

Generate CounterStrings
Configurable length and delimiters
Generate Random Data From Regex
Generate Character Ranges
Repeat text, characters and regex
Add generated data as value, with input event, to an input field
Trigger Key events to ’type’ the data with configurable speed
Binary Chop Calculator for field length exploration

Some of this was a result of migrating code from my Java Test Tool Hub (which I think I worked on about 12 years ago):

https://github.com/eviltester/testtoolhub

From the Test Tool Hub I took the:

Robot - I had to find a different way of triggering events, but this allows ’typing’ the data into the field rather than just amending the value.
Increased customization of the CounterStrings
Ranges of Data
Repeated Data
Binary Chop Range Calculation

And the Data from Regex was repurposing some code from my AnyWayData.com test data generator which uses the same JavaScript library to generate data from a Regex - RandExp

CounterStrings

I wrote about CounterString Algorithms in an earlier blog post.

This extension uses both reverse generation and forward generation.

I initially learned about CounterStrings from James Bach. James has a tool called PerlClip which is a command line tool to generate data directly into the clipboard. This uses a reverse algorithm where the full string is generated and then reversed to paste into a field.

A forward algorithm allows ’typing’ the String character by character without generating the full string first.

While I don’t generate the full String first, I do precompute a Schema which I then follow to generate the String, so it takes about the same processing time, but uses less memory and allows streaming of the result.

I created a different algorithm this time, which is much simpler to understand, but probably takes longer to execute. I’ll need to update the algorithm page at some point, but you can see the algorithm implemented in the source code.

github.com/eviltester/counterstringjs/blob/master/extension/js/generateSchema.js

Other CounterString Tools

A quick hunt around the web revealed a few more CounterString tools that I don’t think I had found all of these before. So these might be interesting for anyone thinking of creating their own implementation.

PERL: https://www.satisfice.com/download/perlclip
TYPESCRIPT: https://github.com/j19sch/counterstring/
RUBY: https://github.com/jamesmartin/counterstring
JAVA: https://github.com/eviltester/testtoolhub
PYTHON: https://github.com/deefex/pyclip
RUST: https://github.com/thomaschaplin/rust-counter-strings

Another Chrome Extension:

https://github.com/Pawel-Albert/utilities-for-testing-extension
- and some associated Test Pages that I haven’t seen before
- https://pawel-albert.github.io/utilities-for-testing-extension/

Software Testing Podcast - AI Optimism or Pessimism - The Evil Tester Show Episode 029

Alan Richardson — Thu, 18 Dec 2025 09:00:00 UTC

Rather than retrospect on the year in general. This podcasts looks at how I’ve been approaching the learning of AI. Where the industry has gone wrong and what to look forward to with AI.

AI Optimism or Pessimism

I sat down to think what am I optimistic about, and what am I pessimistic about with the Software Development industry’s use of AI.

I see a lot of positive benefits for AI use in the Software Development Process.

There are many risks involved with adding AI into products and we should rightly be concerned about those and try to identify how to test AI enabled applications properly.

Many of the statements concerning how Software Testing has to evolve concern me. e.g. more technical skills, more focus on risk, point out flaws in process, identify architecture risk. I thought Software Testing already did this. So perhaps one good thing from AI is an evaluation of what part Software Testing plays in the Development Process and what are the fundamental skills and knowledge we need in order to Test software effectively.

AI Productivity

I’m incredibly optimistic about what I can personally do with AI. It’s massively increased what I can get done, especially in programming, content creation, and marketing.

But companies are cutting jobs and blaming AI. But companies have always looked for scapegoats when trimming staff AI is just the latest excuse.

If leadership truly saw their people as the reason for their growth, they’d use AI to amplify productivity and expand the team’s capabilities, not use it as a reason to shrink down.

“If companies viewed the staff as a core engine for growth, they wouldn’t want to get rid of people when AI comes in. They’d want to use AI to make the staff more effective and grow the company. Clearly they don’t.”

Many management teams see staff as a cost center, not as an engine for growth. Sales gets viewed as the engine of growth and is often paid on commission, so it seems cheap. The product is a ’thing to be sold’. And management… are always essential.

Some organizations don’t think “how do we help our people do more?” They take the position: “how can we do the same (or less) with fewer people?”

AI is the scapegoat. Not the cause.

Short-Term Pessimism

AI is overhyped. Leadership decisions are being made based on hope, not the technology’s actual capabilities.

In the short term, I’m a bit pessimistic, not about AI itself, but about how people (management) are choosing to react to it. Too many seem to want to use AI to restrict and constrain, instead of to grow.

But our work is already changing. New tools exist. We can’t afford to be complacent. We need to experiment and figure out where AI makes sense.

How Should We Use AI?

Not every product needs AI enablement and features. Too much risk, particularly if you do not know how to test the results.

I do NOT use AI for direct human-to-human communication.
- If you get an email from me, I wrote it. If I get one from you, I read it, not an AI.
I would not use AI for company procedures or performance reviews.
- Adding AI to these human, recognition-based workflows is a mistake.
I won’t use AI as a buffer between people.
- Don’t use AI to hide. Engage.

I do use AI to summarize public podcasts, blog posts, etc, Stuff I choose to consume, but not personal, direct communication.

Management is about people, and putting an AI buffer between you and your team leads to bad communication and alienation.

“Your boss should already know what you’re doing. They should be helping you explain the value that you’ve added. This is a human process of recognizing value. It’s not something that we add AI into the middle of.”

How I learned AI

When I started playing with AI, I created a podcast summarizer. My process for learning anything new is to find a project and use the new technology to build something.

I wanted to consume more podcasts but couldn’t keep up. So, I wrote a tool using:

Hugging Face libraries
Whisper AI for transcription
Different LLM models for summarization
Prompt engineering
Ollama for running models locally
OpenRouter for connecting to cloud-based models

I did everything locally as much as possible, partly to learn the limits before relying on cloud or paid models. Only after learning the limits did I see real value in some of the paid services.

Don’t believe in ‘magic’ from big models until you know what smaller, free models can actually do.

Step By Step Adoption

Step 1: Chat Interfaces

At first, I used AI the same way most people, from a chat interface, like ChatGPT or Claude. It worked but had limits. I wanted something embedded into my IDE.

Step 2: Embedding into the IDE

Now, I use a plugin called Continue, which works in both IntelliJ and Visual Studio Code.

Initially connected to Ollama (local code models)
Later I Switched to OpenRouter for bigger cloud models

So now, I can:

Jump into a chat interface via my IDE
Still use chatbots like Claude/ChatGPT for generic things
Never look at Stack Overflow anymore, everything’s in the IDE chat

Step 3: Agentic Coding

I started using agentic tools, like OpenCode, on the command line. They can scan my whole codebase, not just what’s open in the IDE.

I use it to:

Create a page object model for a URL
Write a test for that model
Generate K6 Scripts
Create swagger files
Write scripts
Write API Abstractions
… so much

Now instead of:

Writing the test
Building abstractions and models manually
Iteratively improving

I let the AI generate code, then I come in and change or adapt what I need.

“I’m using it as a tool to help me create things faster. Then I come in and use my knowledge and experience to review the code or expand it.”

Step 4: OpenSpec for Better Requirements

OpenSpec helps generate and maintain evolving and up to date requirements documentation.

Specs are continuously updated as requirements change
OpenCode has documentation to work from, in addition to my prompts

When I use OpenSpec, I’m letting the Agentic Coding Assistant write even more code, than when I use it iteratively at the CLI.

This has helped me:

write a new application faster
Keep requirements and documentation in sync
Automate coverage incrementally

I’m not sure how well it would scale to a full team, but it works well for a solo dev.

But…

AI sometimes makes strange design choices
If you don’t review and refactor, your codebase can fall apart fast
Human review is still necessary

AI saves time, but still requires fundamental core skills to evaluate their output and fix them when they go wrong.

I use AI for programming all the time, but not for actual testing.

Agentic AI in Testing

I’m beginning to look into Agentic AI tools specifically designed for testing.

I’m currently experimenting with AQE Fleet from Dragan Spiridonov

Pros and Cons

Right now, I am optimistic about AI empowering individual development team members. It makes us faster, and the tools are getting better.

But I am pessimistic about the way companies choose to adapt to AI. Focus on headcount reduction instead of increased effectiveness and growth.

What is Testing?

“I keep seeing posts that testers need to evolve into quality engineers and risk analysts and customer experience advocates because we’ll be reviewing the systems for risk more than we’re and testing them… but I thought we already did those things.”

People keep saying testers now need to be risk analysts, customer experience advocates, technical experts, etc. But that’s what good testers have always done. It almost feels like AI is forcing companies to rediscover what software testing really is, and always has been.

Free Technical Web Testing Course Released To Youtube

Alan Richardson — Thu, 18 Dec 2025 09:00:00 UTC

TLDR; Technical Web Testing course has been released to YouTube as a 6 hour video.

Free Technical Web Testing 101 course

Watch on YouTube

Slides etc. can be found via the course page

Practice Sites Now

The sites I use in the course are a little old.

If you want to practice with the techniques in the course then I maintain lists of sites to practice with here:

Course History

The course was created in 2013 or 2014. Originally as a free course, then I added a bunch of content and it turned into 6 hours plus 3 hours of additional webinar content.

Every course provider I hosted it on has changed terms and conditions multiple times making it painful to maintain and support.

Since the examples and videos are now showing their age, and one course provider changed their terms and conditions so much that I now no longer have access to their course platform and can’t support it.

I decided to make the course free.

The course is too big to make free on Udemy so I’ve combined all the videos into one and made them free on Youtube.

Thanks to everyone who supported the course over the years.

An overview of the Basic Shopping Cart Practice Web Page

Alan Richardson — Mon, 15 Dec 2025 11:19:00 UTC

TLDR; an overview of the basic shopping cart that you can use to explore, automate through the UI or REST API and perform security testing on.

The Shopping Cart Application offers a lot of possibility for testing due to the multi-state and multi-page nature. With the added bonus of a REST API which is documented using OpenAPI spec there are even more ways to interact with it.

Find the Shopping Cart Application Here

Overview Video

The video provides an overview of the shopping cart:

Watch on YouTube

Shopping Carts for Practicing

This is not the first Shopping Cart practice Application.

I know of:

SwagLabs Saucelabs demo application.
Toolshop from this has multiple versions
Restful Booker could be classed as a shopping cart
and my Basic Shopping Cart

SwagLabs is pure JavaScript so there are no HTTP calls, but you can explore and test the interaction with local browser storage, and the various users that you can login with change the display so you can use it for visual testing and admin access.

Toolshop, Restful Booker and my Shopping Cart all have APIs and the data is cleared regularly. I think Restful Booker clears data every 15 minutes. Shopping Cart clears data on a rolling basis by limiting the amount stored, so if there are a lot of users at any one time (about 200+), you might notice your old orders clearing from the backend.

When I was designing the Basic Shopping Cart I very deliberately chose to make sure that there was no possible way of having any PI data in the system. This meant that the checkout process does not ask for email addresses, credit card details, or even passwords. The users are ‘canned’ with pre-defined passwords. This means you can perform security testing without any issues.

Really you shouldn’t add any PI data to any testing practice site, but when applications use forms, the auto-complete might be switched on, and your details might be auto-populated into the form.

I do like the other Shopping Carts and have used all of them when practicing my testing.

Why A Shopping Cart?

Shopping Cart applications offer a lot of scope.

There tend to be multiple pages offering navigation scope.
Pagination if there are enough products.
API and server side interaction.
Checkout Process has state - tracked locally via cookies or browser storage, and possibly server side as well. Having state in two places offers scope for state moving out of sync and creating mismatch between server and client.
Usually a registration or login process. Which also lends itself to security testing.
Tend to be content rich.

Content rich applications are interesting. The first time we automate them we tend to hard code product names and ids. Then we realise that there is usually a CMS (Content Management System), and users can edit content, which then causes our automated execution to fail.

This might lead us to using the API and UI as a consistency Oracle for content. Does the API serve data consistently. Is the data rendered correctly. So we don’t automate or test exclusively through the UI, we use the UI and API in combination when we want to assert on data conditions.

Creation of the Shopping Cart

To build the application I started API first. The API was completely hand coded. This meant that I could test the flows and the functionality before spending any time on the UI. I was able to experiment with various authentication flows and data representations until I had one that I thought was rich enough and removed any PI risks.

Once I had the backend covered I used OpenCode to incrementally add basic REST API automated coverage, and then expanded the coverage.

Frond End Creation

I wanted the front-end to be simple JavaScript, HTMl and CSS, and avoid the use of frameworks.

My Test Applications are designed to be entry points. They will be challenging enough naturally, so I didn’t want to clutter the learning effort for people practicing by using React.

The Front End was creating by prompting through OpenCode and then I would amend and refactor where necessary. This allowed me to create the front-end quickly. But because I prompt in very small increments the code is more closely aligned with the style of coding I use, and makes it easier for me to amend in the future.

The models used were spread across free models from OpenCode Zen.

Grok Code Fast 1

Or I used Kat Coder Pro (free) on OpenRouter.

I try to use a mix of models in the CLI, and then a different set of models in the IDE. In the IDE I have Continue configured to use OpenRouter models.

Creating Content

Al the content was generated via AI tooling.

I prompted GTP-OSS-20B via OpenRouter to create 100 ’thing’ name variations. I fed it the sample ’thingy’ words and adjectives. I could have varied this more, and I could easily have used a normal combinatorial algorithm to do this but the AI interface was fast enough.

With a set of 100 names, I then asked for one line descriptions, using the same process. The are all output as JSON to make it easy for me to amend in the code.

Since this data is ‘content’ I can vary it over time. For the first release I just need 100 different products to add to the product list.

Creating Product Images

Generating the images was a little more interesting.

I am deliberately trying to keep my AI cost as low as possible to see how far I can push my use of AI with minimal cost.

My biggest cost on OpenRouter was using Nano Banana to create 2 experimental images when it was first released. The Nano Banana images cost 50c each and they didn’t end up the way I wanted. This was not an experiment I wanted to repeat with the product images. I’d need at least 100 and I might want to regenerate them if they didn’t work out.

First I tried image generation models through the local install of localai.io but I don’t think my machine is powerful enough. The process was slow and the output was basically a random png and completely unsuitable.

Rather than spend another couple of hours experimenting to improve this, I decided to try one of the image models on OpenRouter. These are easy to automate but past experience made me hesitant. However, as I was looking at the costs I noticed that the image pricing was quite cheap for one of the models, but this was only shown in the comparison page.

https://openrouter.ai/compare/openai/gpt-5-image-mini/google/gemini-3-pro-image-preview

GPT 5 Image Mini was estimated at $0.002 per K generated.

I didn’t expect to have good results with this but I tried it through a simple prompt and was surprised at the image quality.

It took me about 20 minutes to write code to call the API and experiment with prompts. This led to some good random product images and they were about $0.007 per image, so I could generate 100 images for about $0.70.

I used the product descriptions generated earlier and fed them through into OpenRouter with my script to generate the images you can see in the product pages.

Generating Image Descriptions

Rather than use Lorem Ipsum I wanted to generate fanciful and long descriptions for each of the products.

I wanted to use AI to generate a fuller paragraph style description of each product.

I found that the lava:7b model will run nicely on Ollama locally and it is very small. It has vision capabilities, so it can read images.

https://ollama.com/library/llava:7b

It only consumes about 5gb when running so it fits comfortably in my GPU memory.

I used this via api calls to describe each of the images in turn. I was very surprised at the quality of the descriptions when running locally.

This worked out well enough for my experiment and in total cost around $0.70 to generate and describe 100 images.

I thought that 100 was enough to allow pagination experiments and build on over time.

In total to do all this programmatically took about an hour to write code and 4 hours to run.

I think it would probably have taken longer for me to search the web, find a tool to do all this, if a single tool even existed at all.

Tool Vendors Take Note: it is becoming easier and easier for people to create their own tooling, cheaply and with the exact functionality they need.

Automating the Web UI

I used OpenCode to generate the Page Object Models and an initial set of coverage, I then amended and refactored to expand the coverage as I required.

This has become my normal approach to generating automated execution code now. This is also different from the way I code manually.

When coding manually:

I write the test first,
and grow the Page Object Model organically through refactoring,
this way I only create the abstraction code that I need in the test.

When coding with AI, I reverse this:

I generate the Page Object
- I give OpenCode access to the Chrome Dev Tools MCP so that it can read the DOM and it generates accurate locators. Sometimes I refine them, but they are usually good enough.
During the Page Object creation, in the same prompt I ask for
- “A set of basic tests which use the Page Object Model methods to cover the basic functionality. Do not test the Page Object, use the Page Object to avoid putting any locators for ‘driver.’ methods in the test code.”.
I then review and refactor.
Then I iteratively expand with small prompts, targeting specific coverage with each prompt.
I’ve found this works well, avoids rework and is fast.

Automating the REST API

I prompted OpenCode to read the routing code that I had written in Java for the API and create basic coverage for the each of the API end points in turn. This led to the creation of the payload objects and incrementally build up an API abstraction.

By targeting each endpoint individually I could gradually grow the code, keep control of it, make sure it was using my style of coding and automating and didn’t need a lot of refactoring later.

I then prompted to recreate the UI automated execution flows using only the API abstractions that I had just built up.

Testing

The general rule we are told is that you test first, then automate. You can see from the above description that I do not abide by this rule.

I used the automated coverage to handle the basic flows and flush out any simple errors. This creates an automated safety net that can help me when I’m fixing any issues that I find from testing. Without the basic automated coverage I might introduce more errors when fixing bugs than I remove.

Testing was performed via exploration using Chrome, heavily reliant on the dev tools and viewing requests in BurpSuite.

I then moved on to testing the REST API directly.

This helps me build up a list of issues, some of which I fix, but since it is a testing app, some of them I don’t.

The automated coverage tells me that it can work. My testing convinces me where it fails to work.

Security Testing

I coded in some security issues, so I made sure to test these.

I used Bruno as my API client to explore all these issues.

Some of them I removed because they would be annoying to the user if exploited when they were trying to test the application, so they are primarily information leakage rather than amendment. But… it might be possible if you test deep enough.

The only tool used during this process was Bruno to issue requests.

Performance Testing

I didn’t want to go live with the cart unless I could convince myself that it could handle multiple users.

I used OpenCode to convert my API automated execution scenarios into K6 scripted scenarios such that I could scale Virtual Users and hit the application functionality.

I do not recommend the Shopping Cart as a target for performance testing, that isn’t what it is designed for.

Butch Mayhew maintains a list of sites designed for practicing Performance testing against in his Awesome Sites To Test On

Two from Blazemeter and one from OctoPerf:

This took me about an hour in total, because I had to fix a couple of errors in the generated k6 script, but I think using OpenCode saved me a couple of hours since I’m not a K6 expert and have to re-learn it every time I use it.

Software Testing Podcast - BrowserStack Community QnA - The Evil Tester Show Episode 028

Alan Richardson — Fri, 12 Dec 2025 09:00:00 UTC

The answers given during an AMA session held on Discord on the 11th of December 2025, following a live LinkedIn video stream. The session focused on “Mastering Automatability for Test Automation”. The main theme is the concept of Automatability, which I view as the ability to automate, this personal skill is more critical than reliance on specific tools. The discussion covers various topics, including how to separate automation problems from application design issues, dealing with slow UIs and non-automation friendly third-party widgets, evaluating automation readiness, and addressing common architectural failings related to large-scale UI automation.

Discord And LinkedIn

This was a Browserstack hosted event. The initial Q&A session started on Linkedin with a conversation between Alan Richardson and David Burns.

Recording can be found here:

LinkedIn Event

The session then moved to Discord. The Browserstack discord has many AMA and interviews so is worth signing up to have a look at.

Other AMA sessions include:

Join the BrowserStack Community on Discord and discover many more sessions, videos and conversations.

https://www.browserstack.com/community

Q&A Session Questions and Summaries

I’ve listed the questions and summary answers. Full answers can be found in the podcast, audio or video, or on the Discord AMA chat.

Q&A 1: Understanding Automatability for a First Automation Framework

Question: If I’m building my first test automation framework, what’s the one thing about automatability I should understand?

Summary of Answer:

The most important thing to understand is that automatability refers to your ability to automate. By having a strong ability to automate, you become less dependent on specific tools, making it easier to create workarounds and choose from multiple tools. Developing experience in how to automate allows you to succeed more often, and means you are not reliant on a tool interacting with your system, which makes workarounds harder. Automating is fundamentally about your understanding of what and how to automate, and practicing the application of that ability.

Q&A 2: Separating Automation Problems from Application Design Problems

Question: How do you separate automation problems from application design problems?

Summary of Answer:

If an issue causes problems when you are automating, I would call it an automation problem. While this problem might be triggered by an application design problem (such as a state-based system that is hard to track, or features that are harder to automate), the issue itself remains distinct. If the team cannot change the application design, they must figure out how to automate the application as it is. This might involve absorbing the issue, figuring out how to automate it at a different level (not end-to-end), or handling it through testing processes using observability tools like DataDog.

Q&A 3: Slow UIs and Testability/Automatability

Question: When dealing with slow UIs is the slowness a testability issue an automatability issue or both?

Summary of Answer:

Slowness is likely both, and more, because it is also a usability/user experience issue. If the slow UI impacts the user experience, it is more likely to be addressed than if it only impacts testing or automation. In cybernetics terms, testers or automators must possess the “requisite variety” to handle the variety (slowness) in the system being tested, which means knowing how to synchronize or potentially cleaning the environment to improve speed. The focus would be on the impact of the slowness, rather than the slowness itself, and whether the team or its tools can absorb the variation in response times.

Q&A 4: Handling Non-Automation Friendly Third-Party Widgets

Question: How do you handle third party widgets like payment gateways that are inherently not automation friendly?

Summary of Answer:

If a third-party widget is “not automation friendly” for one tactic (e.g., UI automation), it might become easier to automate by adopting different tactics, such as issuing HTTP requests using cookies collected from the UI. Teams may not need to automate the full flow of the widget, but instead focus on ensuring the widget is wired up correctly within their own application. This can involve only testing partway through the flow, or using a mock or stub in the environment so that the full widget flow doesn’t need to be tested constantly.

Q&A 5: Evaluating Automation Readiness and Consultancy Frameworks

Question: How do you evaluate an application’s automation readiness during consulting? Do you follow a framework?

Summary of Answer:

I do not use a formal consulting frameworks. The closest methodology used is the meta model from Neuro-Linguistic Programming, which involves asking questions to build a model of the client’s environment and processes, comparing it to the reality they face.

learn more about NLP and Testing in this paper I wrote.

Regarding automation readiness, an application is considered ready to automate “as soon as someone wants to automate it”. Readiness is judged by whether the client is prepared to commit to whatever it takes to automate the application at that specific point in time to achieve their desired outcomes, regardless of the application’s current state.

Q&A 6: Architectural Patterns Failing in Large-Scale UI Automation

Question: What architectural patterns do you see repeatedly failing when it comes to large scale UI automation?

Summary of Answer:

Recurring issues often stem from the team lacking the ability to automate and consequently blaming the tool for problems, rather than creating necessary workarounds. Common process anti-patterns, not strictly architectural patterns, include deploying differently into test and production environments (not using the same install process).

A major failure point is test data maintenance, especially trying to use production data or any data that the team does not control. Automating against specific data conditions without control over that data causes random test failures. This can be worked around by hardcoding tests against data conditions instead of specific data, and dynamically selecting the required data during execution.

Q&A 7: Prioritizing Testability and Automation in Sprint Planning

Question: If testability improves debugging and automation improves scale, how do we prioritize them during sprint planning?

Summary of Answer:

Prioritization can be based on what the team wants to achieve (the outcomes) by the end of the sprint, specifically focusing on the expected coverage from testing and automation. It is beneficial to plan for features that need extensive testing to be delivered early in the sprint. Ideally, testing and automating occur in parallel, and teams automate at lower levels (like unit level) to reduce the necessary coverage at the higher UI level. Issues often arise when teams are divided into isolated roles, creating process problems that hinder effective interaction and prioritization.

Q&A 8: Playwright and the Illusion of Reduced Automatability Design Needs

Question: Do modern frameworks like Playwright reduce the need for high automatability design or is that an illusion?

Summary of Answer:

It is an illusion. Frameworks like Playwright are designed to absorb application variability through features like retry mechanisms (for synchronization) and locator strategies (like visible text), which reduces the need for constant notification when minor changes occur. This absorption capability makes Playwright effective for agent-based automation where the goal is checking an end-to-end path and the final result.

However, this absorption can hide issues that a team might want exposed. Even when using Playwright, developers must still understand how to automate and structure their code using abstraction layers (like page objects, domain objects) to ensure long-term maintainability and efficiency.

Q&A 9: Explaining Automatability as an Investment to Leadership

Question: How do I explain to leadership that improving automatability is an investment not a delay?

Summary of Answer:

The explanation depends on what is being improved. If improving automatability means increasing the team’s ability to automate, it can be presented as an investment in staff training. If it involves adding technical aids (like IDs in the UI), leadership might perceive it as a delay because they may not value UI execution coverage or may already be confident in unit-level automation. To convince leadership, the team could demonstrate the return on investment by showing the alternative world. This involves comparing the current reality to a scenario where improved automatability allows the team to do beneficial things they otherwise couldn’t, thereby highlighting the value gained.

Q&A 10: AI Agents Dealing with Dynamic Elements

Question: We are exploring AI agents for our teams and I want to know how does the AI agent deal with dynamic elements like rotating banner banners, third party widgets or AB tests?

Summary of Answer:

How the agent deals with dynamic elements depends on how it works (e.g., building high-level BDD scripts or generating code). Agents often operate on first principles. If an agent uses a BDD approach, it works from a runtime specification and handles dynamic elements because it works from scratch for each execution, constantly aiming to fulfill the objective. For example, if an unexpected pop-up appears, the agent clears it and continues.

If the agent writes code, it uses what is often called “autohealing”. This process automatically amends the script based on the current application state, prioritizing the achievement of the objective regardless of whether the change is “right”.

Q&A 11: Early Signals of Flaky Features

Question: What early signals tell you that a feature will become flaky once automated?

Summary of Answer:

Early signals involve understanding the synchronization points of the page. A feature is likely to be flaky if the application is populated or amended over time by JavaScript and the automation tool is not synchronizing properly on the DOM buildup. If a page is being constantly updated in the background without clear visual indicators (like spinners, which are easy to synchronize on), flakiness is more likely.

The signal is the update process itself, particularly when it is non-deterministic (e.g., how totals are updated in a shopping cart). The core question is whether synchronization is required to prevent flakiness, and if it is difficult to synchronize, that is a strong signal. If necessary, automatability might be enhanced by adding an extra flag to the DOM to signal when the update is complete.

Q&A 12: Layers to Focus on in Microservices for Automatability

Question: In microservices setups which layers should teams focus on first to increase overall automatability?

Summary of Answer:

The foundational layer to focus on is the human understanding of the architecture and the requirements for automation. In microservices specifically, teams would typically focus on the interface layer and their ability to automate it while keeping the interface standard.

If microservices are communicating via HTTP messages compliant with a version standard, automation can be relatively easy. If interfaces are internal and change randomly, issues may arise, requiring attention to managing event-based queues if applicable. Strategies include using versioned interfaces or having a process to update automated coverage and abstraction layers when microservice interfaces change. It is crucial to avoid replicating interface objects (like payload objects) directly into test code, as this can prevent tests from spotting issues when new or removed fields occur in the application interface.

Q&A 13: Budget-Limited Automatability Fixes for Fastest ROI

Question: For a team with limited budget which problems around automatability should we fix first to get the fastest return on investment?

Summary of Answer:

The fastest return on investment comes from enhancing the team’s ability to automate. This improvement allows teams to develop workarounds, find alternative solutions, and identify when to use different techniques. It is not about purchasing multiple or expensive tools. Instead, investment could be placed in training, practicing, exploring the capabilities of existing tools, and eliminating fundamental issues like test flakiness by fixing the root causes.

Q&A 14: Collaborating Earlier to Avoid Automatability Rework

Question: How can developers and testers collaborate earlier to avoid expensive rework on automatability issues?

Summary of Answer:

Collaboration is achieved by removing the barriers that cause people to be isolated into silos, such as separate programming, testing, or test automation teams. The core issue is often that a “development team” is defined only as a programming team, instead of encompassing responsibility for design, programming, product suitability, testing, and production.

Practical steps include involving the programming team in the automated execution maintenance. When programmers contribute, they often ensure data IDs are present, which removes many hard-to-automate issues typically found during end-to-end testing. Sharing the responsibility for maintenance ensures people understand and resolve related issues earlier.

Q&A 15: Automatability in Continuous Delivery and Trunk-Based Development

Question: How should teams think about automatability when shifting towards continuous delivery and trunk-based development?

Summary of Answer:

This environment requires high automated execution coverage that runs quickly, often with features being merged multiple times a day. Automatability is achieved by ensuring the person or pair responsible for creating a feature is also responsible for adding automated execution coverage (unit tests). These tests demonstrate that the feature has been tested and provide future checks against accidental changes impacting the functionality.

Teams could focus on structuring unit tests at the domain level (e.g., focusing on users or orders) rather than strictly class level. This approach results in a degree of internal end-to-end flow tests without needing extensive external system testing. Furthermore, application architecture can be designed so that interfaces (like HTTP interfaces) can be tested primarily at the domain level, reducing the need for numerous actual HTTP calls.

Convert Chrome Dev Tools Recording to WebDriver Java Code Using Free OpenCode AI Agent

Alan Richardson — Mon, 24 Nov 2025 10:19:00 UTC

TLDR; Record and Playback is a notoriously bad way to automate. But what if we record, then have AI write code from the recording? Answer: it is a little better.

I performed an experiment to try tand demonstrate how to replicate the AI-powered test automation features commonly found in commercial SaaS testing tools using open source solutions. The process involved recording user interactions in an application with Chrome DevTools Recorder, exporting the recording as JSON, and then using an AI tool to convert the JSON into JUnit tests with WebDriver and page objects.

Overview Video

Watch on YouTube

In this video I:

record some web actions using Chrome Dev Tools recorder
fail to play them back because record and playback is notoriously bad
feed the recorded JSON file into OpenCode with a prompt
check the results of the AI process writing Automated Execution using WebDriver and Java

We do get working automated coverage out the back. I would need to edit it a little, and if I wanted to do this longer term I would need to amend the prompt to meet my coding preferences.

process

I used the triangle application on Test Pages:

https://testpages.eviltester.com/apps/triangle/

Test Pages has a deliberately hard to automate side bar. The easy automation is through the top level menu.

But I recorded the Triangle application by:

clicking on the side menu bar to open the Triangle application
and the instructions
reading the instructions
clicking back on the triangle application
interacting with the app to generate invalid and valid triangles

When I tried to playback the recording in the Chrome Dev Tools, it failed.

Most of us experience failure with record and playback tooling.

AI tooling

I have OpenCode, configured to use Chrome Dev Tools MCP, and working with Kat Code Pro Free in OpenRouter, but could just as easily have used any of the free coding LLMS on Open Code Zen or with Ollama locally.

I used a basic prompt

The process took about 5 minutes to run.

It opened the web page a few times,
created some Page Objects.
Found that the menu interaction was hard.
Decided to jump straight to the triangle page and automate that way
It did replicate the functional interaction included in the recording
it did generate assertions for the results
I could have used the test code generate with some small amendments.

Lessons Learned

SAAS tools which take this approach will use Agents, which are essentially longer prompts. I should have added into the prompt more conditions:

“given the json attached, convert the json into a set of junit tests using webdriver and page objects to recreate the flows recorded by the user. The json file is a recording made in Chrome Dev Tools recorder. In the test code, do not write any findElement code, always abstract the location and interaction into a page object. Use existing page objects where possible and try to re-use existing methods. Make sure that any page object methods you use are used in a test so we have coverage of the interactions.”

Over time, if I wanted to continue to automate using this process, I would refine the prompt further until I got the results I wanted, and possibly encode this prompt as an agent.

Would I do this?

Unlikely that I would do this in the real world.

This seems like the replication of a record and playback approach.

I do create Page Objects and have created initial execution coverage using AI.

I have some empathy for AI tooling scanning applications and building flows through the application to automatically interact and generate a wide variety of data, to increase the scope of coverage across a few simple flows. I can see potential in augmenting a team to allow the team to go off and do more detailed stuff. Provided the AI tooling doesn’t get noisy and keep distracting the team.

For any functionality as simple as I experimented with here, I hope that when people evaluate SAAS tools, that they also compare the paid tools to the capabilities of Open Source tools.

Nothing wrong with paid tools. They are incredibly valuable when they make hard things simple, and add value when they make hard things easier.

But, when the activity is simple and the functionality differences between Open Source and paid are small, I hope companies consider “what if we upskilled our staff a little such that we could use the Open Source tools”.

Using Free OpenCode AI Agent to create Page Objects for WebDriver with Java

Alan Richardson — Thu, 20 Nov 2025 10:19:00 UTC

TLDR; OpenCode is a free and easy to use AI coding agent, it can be coupled with free models and MCP servers to create test automation code quickly and easily.

I had two sessions using Grok to create Page Objects.

The recorded session was the second, and it did not go as smoothly as the first.

Overview Video

Watch on YouTube

Curious about coding test automation with free AI tools? See how OpenCode generates page objects and WebDriver tests in real time. Also see the Chrome DevTools MCP Server in action so that the locators are pulled from the DOM, reducing manual effort in creating Automated Execution Code.

In this video I used Grok Code Fast 1 because it is currently free on OpenCode Zen, so anyone can repeat the experiment without additional requirements or funds.

Code

You’ll find AI Generated code for on Github:

https://github.com/eviltester/ai-supported-testing-experiments/tree/main/opencode/create-page-object

The application under test:

https://testpages.eviltester.com/apps/text-transformer/

Accelerating Test Automation with OpenCode and AI

I’ve been using OpenCode, a free, command-line interface for AI-driven code generation, to build page objects and tests for a WebDriver Java project. When configured to use Chrome DevTools MCP, the AI Tooling can pull down the DOM from the page under test and use it to create accurate locators and coverage flows.

What is OpenCode and Why Use It?

OpenCode is a completely free CLI tool for operating code agents. Running from the terminal, you can use AI models to generate code automatically. OpenCode supports a variety of model providers:

OpenCodeZen (completely free for certain models, no billing details required)
- https://opencode.ai/zen
OpenRouter (paid credits, but many free models as well)
- http://openrouter.ai/
Possibility to run local models with tools like Ollama, keeping everything on your machine
- https://ollama.com/

Switching between models is easy, letting you experiment and find which AI delivers the best results on your codebase.

During my WebDriver code experiments I’ve used Grok Code Fast 1, Kat Coder Pro, GPT-5 Nano.

GPT5 Nano didn’t give good results, while GROK Code Fast One did better. Through OpenRouter, Kat Coder Pro (free) with occasional use of Claude Haiku 3.5 have been my main models.

Practical Use Case: Building Page Objects and Tests

The core of the demo is applying OpenCode to a Test Transformer application on Test Pages. A page where users enter text, which is then manipulated in various ways (e.g., reverse, Pig Latin, ROT13, etc.).

The page also has cookies to track visits and last used text. There is no ’transform’ button and text is transformed automatically as the text changes.

Using OpenCode

Automatic Page Analysis: By integrating with Chrome DevTools MCP, OpenCode can launch a browser, analyze the DOM, and retrieve locators with high accuracy.
Prompt-driven Code Generation: You can specify exactly what parts of the page you want covered. I keep prompts focused, asking for page objects that cover only relevant fields and results.
Iterative Improvement: Results can be variable. Sometimes you get exactly what you need, sometimes less, sometimes more. But with targeted prompts and reviewing, you can guide the AI toward better outcomes.

MCP Configuration

OpenCode has a configuration folder in the user directory, so I amended it, as per the instructions on the web site, to use Chrome DevTools as an MCP Server.

This allows the AI to use the browser and analyze the DOM:

{
  "$schema": "https://opencode.ai/config.json",
  "theme": "opencode",
  "autoupdate": true,
 
   "mcp": {
	"chrome-devtools": {
             	"type": "local",
      		"command": ["npx", "-y", "chrome-devtools-mcp@latest"],
      		"enabled": true
      },
   }

}

Page Object and Test Creation: Challenges & Strategies

The generation process is interactive:

Refining Results: Initial code may be too generic or incomplete. By referencing exact DOM elements (IDs, etc.), you can guide the AI for more precise methods and cleaner tests.
Decoupling Structure from Tests: I had to guide the AI to improve the design by avoiding dependencies where tests need to know page structure, relying instead on abstractions implemented as page object methods.
Handling Edge Cases: Randomized features (like word shuffling) require smart assertions e.g., comparing sets or arrays rather than specific string outputs.

Reviewing and Refactoring AI-Generated Code

The AI output should always be reviewed and, when necessary, tweaked. Which means it still helps to know what you are doing, learn how to code, and learn how to automate.

In the video, I check the validity of date-time assertions and tolerances, tidy up method design, and make small adjustments for clarity and robustness. AI can cover a lot quickly, manual review remains essential.

Takeaways: When and Why to Experiment with OpenCode

Speed and Coverage: OpenCode can save you significant time, especially for repetitive or DOM-heavy automation tasks.
Variability: Different models (and even the same model, run twice) yield different results. Prompt engineering and manual review are key.
Cost-Effectiveness: Thanks to the availability of free models, you can lower the barrier to entry for AI-powered test automation.
Flexibility: Whether you want cloud-based AI or local execution, OpenCode can accommodate diverse workflows.

Final Thoughts

OpenCode is a powerful tool for testers and developers looking to speed up automation without a big cost outlay.

You need to know how to code and automate, so that you can effectively review the generated code and prompt for improvements.

By combining intelligent prompting with iterative review, you can build robust page objects and coverage tailored to your applications.

I think it is worth experimenting with OpenCode. Try different models.

An overview of WebDriver with Java

Alan Richardson — Thu, 13 Nov 2025 10:19:00 UTC

TLDR; a simple WebDriver Test is not production ready code, but when we refactor it to use JUnit effectively, add some Page Objects, Abstraction and a little bit of Synchronization and we have all the makings of quality execution code.

This video is an overview of how you can refactor from a simple WebDriver test which is not robust and not reliable, into a production quality UI Automated Execution @Test class.

Overview Video

Watch on YouTube

Step-by-step walkthrough of the essential building blocks for creating robust, maintainable automated web tests. Starting with the most basic “Hello World” of WebDriver, you’ll learn how to interact with web pages, locate elements using IDs and CSS selectors, extract data, and implement reliable synchronization.

Moving beyond the basics, you’ll build scalable test code using JUnit as the test execution framework, and discover how to organize your tests with setup and teardown methods, manage browser drivers, and avoid common pitfalls that lead to unmaintainable test scripts.

The videos covers the Page Object Model (POM), a key design pattern in Selenium test automation. See how to abstract away locators, web elements, and navigation into clean, reusable page classes—making your tests easier to write, maintain, and scale as your application grows.

You’ll also get hands-on guidance for implementing waits, synchronizing with dynamic content, and writing tests that assert on changing page states without flakiness. Real-world design decisions, such as when to expose web elements versus higher-level actions, are discussed, giving you the confidence to craft production-ready automated tests.

Key topics covered:

Selenium WebDriver setup in Java
Locating and interrogating web elements efficiently
Writing basic and advanced JUnit tests for browser automation
Organizing reusable and maintainable code with the Page Object Model
Effective synchronization using WebDriverWait and ExpectedConditions
Managing test environments and abstracting configuration
Common mistakes and how to write production ready test code

Code

You’ll find the code for this on Github:

https://github.com/eviltester/startUsingSeleniumWebDriver

A longer tutorial article with guidance on using WebDriver in CI:

https://testpages.eviltester.com/reference/automating/webdriver/webdriver-java/

The application under test:

https://testpages.eviltester.com/pages/basics/basic-web-page/

Key Concepts

The video covers the essential practices and techniques for building maintainable, robust Selenium WebDriver tests in Java.

Test Structure and Execution Framework

JUnit for Test Lifecycle Management:

Use JUnit as an execution framework to manage WebDriver setup and teardown. Placing driver instantiation and browser closure within appropriate lifecycle hooks (@BeforeAll, @AfterAll, @BeforeEach) ensures resource management and avoids issues such as orphaned browser instances if a test fails.

Single Responsibility:

The test methods are kept focused solely on specific test state and asserting behavior. Setup and environment logic are abstracted away, improving clarity and repeatability.

Locators and Web Elements

Locating Elements:

WebDriver’s findElement with appropriate strategies (typically By.id, By.className, or CSS selectors) is used to interact with page components.

WebElement Abstraction:

Operations on page content—such as retrieving text or manipulating controls—are achieved by first locating and then storing elements in variables, leveraging WebDriver’s WebElement interface.

Environment and Configuration Abstraction

Test Environment Encapsulation:

Test configuration (e.g., the base domain/URL) is factored out into dedicated environment classes or variables. This enables easier swapping between environments (production, localhost, etc.) and increases test maintainability.

Page Object Pattern

Purpose:

The page object pattern encapsulates page behavior and structure. It removes direct driver calls from test code and moves them into dedicated classes, representing pages or components.

Page Object Responsibilities:

You decide on specific responsibilities when you create the Page. The video outlines a few categories.

Locators (how to find the elements)
Navigation (e.g., loading the page)
Element accessors (methods returning individual WebElements for UI components)
Functional helpers (high-level actions such as “click button” or “wait for message”)
Synchronization methods encapsulating common waits or checks
Evolution and Maintainability:
Page objects are built incrementally through refactoring, adding only what is needed for current test coverage. Overengineering is discouraged. Abstraction is introduced to support actual test requirements.

Synchronization and Robustness

Synchronization with WebDriverWait:

Reliable tests require explicit synchronization. Leveraging WebDriverWait and Selenium’s built-in ExpectedConditions guards against timing issues, such as waiting for a message to appear after a button click.

Prefer methods that wait for meaningful state changes rather than only for specific text, e.g., “wait until message is shown (non-empty).” This approach aids maintainability, reduces flaky tests and avoids clashes with Assertions where duplicate test code would be maintained.

Assertion Practices

Assertions in Tests versus Waits:

Assertions should reside in the test methods, separated from waits. Assure the correctness of content after synchronization to ensure tests fail for relevant application issues, not for timing errors.

Avoiding Redundancy:

Abstract common assertions or waiting patterns into the page object or helper methods without duplicating logic.

Scalability and Design Decisions

YAGNI Minimalist Approach:

You aren’t going to need it. Only model what is immediately necessary. Avoid creating exhaustive page objects upfront. Prioritize test coverage and practical needs over future-proofing.

Component Modeling:

Page objects can represent whole pages or reusable components, adapting complexity as the coverage grows.

Exposing Elements:

Whether to expose WebElement instances or hide all interaction behind higher-level methods is a judgment call. Balance flexibility and encapsulation according to project needs.

Summary

Effective Selenium automation in Java entails adopting JUnit for structuring the test lifecycle, abstracting environment configuration, utilizing the page object pattern for encapsulation, applying robust synchronization with waits, and maintaining a clean separation of setup, interaction, and assertion logic. These principles, create automated execution code that is easier to write, read, maintain, and scale as your application evolves.

An overview of the dummy practice web page Basic Web Page

Alan Richardson — Tue, 04 Nov 2025 13:19:00 UTC

TLDR; an overview of how you might use the most basic site on Test Pages. Use dev tools. Explore the JavaScript. Interrogate and Amend the DOM. Go beyond a button click.

This is an overview of how you might use the Basic Web Page on Test Pages.

If you don’t go deep then you’ll read the text, click the button and tick the pass checkbox. But we need to learn to go deeper when performing web testing.

Overview Video

The video provides an overview of what you might explore using the Basic Web Page on Test Pages, software testing practice application:

testpages.eviltester.com/pages/basics/basic-web-page/
Avoid getting distracted. Learn how to zero in on specific page elements so your exploratory sessions have a clear purpose.
Use browser developer tools, inspect and manipulate the DOM.
Discover how to use CSS selectors and XPath for finding and interacting with page. This is not just for automating.
Find out why reading the underlying code can reveal more than just clicking buttons, and how it can help you spot functional risks early.
See how browser-based AI tools can help you experiment, understand selectors, and accelerate your learning. Even on a super basic page.

Watch on YouTube

How a Simple Web Page Can Help You Master Web Application Testing

When learn web application testing, it’s tempting to look for complex scenarios and detailed features. But even the most basic web page can be used to learn a lot of essential testing concepts and skills.

Restrict your Focus

It’s easy to get distracted by the all the elements: sidebars, navigation, tag clouds, menus, etc.

But we need to focus.

The central area contains just three things that matter for this exercise: two paragraphs and a “click me” button.

“It’s important to know that when we are testing applications, there’s often a lot of stuff in the application, but we have to restrict our focus because we’re doing exploratory testing sessions with a particular aim.”

Go Beyond Basic Functional Testing

The most basic functional testing involves checking that the paragraphs display the right text, the button exists, and clicking it produces the intended result “you clicked the button.”

Automating this is simple. But we can use every page to learn more. And pushing ourselves on such simple pages can reveal limits to our knowledge and trigger us to learn more.

I revisit the Test Pages multiple times and each time I approach them differently I push my skills, double check my learning and find something new to try.

Discover the DOM

Learning to use Inspect Element is crucial. The dev tools reveal the Document Object Model (DOM). The browser’s internal representation of what you see.

By inspecting, you learn that your target elements sit within a <div> with class "centered", and that paragraphs (<p>) and buttons are distinguished by IDs and classes.

This exploration raises fundamental questions:

What is a <div>?
What do attributes like ID and class mean?
How can we use these attributes to locate elements?

I don’t try to explain everything on the Test Pages. There are very thorough references on the web to look all this stuff up:

https://developer.mozilla.org/en-US/docs/Web

CSS Selectors and XPath

Finding elements efficiently is a key skill for both exploring and automating:

CSS Selectors: Quickly locate elements by #id or .class.
XPath: Offers more complex navigation through the DOM, including traversing backwards, a feature not possible with CSS selectors.

You can experiment with these directly in your browser, using built-in tools to copy selectors or XPath expressions to pinpoint any element.

AI Assistance

Chrome now integrate AI-assisted features. By asking the AI for alternative CSS selectors or XPath for a specific paragraph, you receive instant help.

A great way to increase your locator expertise and knowledge. And you don’t have to trust the AI, test it all out in your browser dev tools.

You may not need to install extra tools to work with something as basic as a locator.

Eventually you’ll be able to create the locators without help.

Understanding Risks Beyond the Functional Requirements

Technical testing isn’t just about obvious functionality. We need to learn to look for, and evaluate many types of risk:

Synchronization Issues: The “click message” paragraph always exists in the DOM, so automation scripts must check its content changes, not just its presence.
JavaScript Behavior: Only the relevant lines of code execute on click; changing the button’s ID after page load won’t affect the click handler because the event is already attached.

“We have to have the ability to assess the risks of the page we’re looking at, even on a simple page like this, with five lines of code.”

Don’t Panic.

Experiment freely; if you break something, a page refresh will reset it back to normal.

The Test Pages is a safe environment to play. We want to learn without fear.

The Path to Technical Mastery

Even with a simple page like this we can go beyond the basics.

Use it to learn how technology implements functionality, and then use those insights to identify deeper risks and improve your testing.

“Work through the test pages, go beyond just the functionality, learn to understand the technology that implements it.”

An overview of the Software Test Pages, a dummy practice web testing application

Alan Richardson — Tue, 04 Nov 2025 12:19:00 UTC

TLDR; if you want to practice your technical web testing then start with testpages.eviltester.com

Do you want a dummy practice site to use to practice and improve your web testing and automating?

I spent the last few weeks in October updating the Test Pages application to be easier for me to maintain, add more content and generally tidied it up to make the pages more focused on specific concepts and avoid too much functionality on one page.

Overview Video

The video provides a quick overview of the software testing practice pages hosted at:

testpages.eviltester.com

This site is designed as a self-teaching site for anyone learning web testing.

Watch on YouTube

What is Software Testing Pages?

The application is built to help users practice fundamental web testing skills regardless of methodology or tool.

Key areas of suggested practice include:

Exploratory testing.
Automating using various tools.
Learning testing tools, proxies, and browser dev tools.
Learning web technologies.

The site links off to other high-quality practice testing sites, making it a central reference point. I’ve curated a list of what I consider to be the best practice sites, and the ones that I’ve used. I skipped any with lots of bugs, or that don’t seem to be maintained.

Practice Sections: Pages and Applications (Apps)

The site is organized into categorized sections that target specific functional areas and concepts.

Pages (Basic Testing Practice)

The “Pages” section is ideal for those just beginning their learning journey. These pages cover fundamental concepts and element interaction:

Basic elements: Examples include a basic web page with a button that can be clicked and automated.
Element location: Users can practice finding elements by tag name list or by ID. This practice can be done using automated execution tools (like WebDriver or Playwright) or directly within the dev tools using CSS selectors.
Alerts and interactions: The site includes standard JavaScript alerts (pop-up boxes), as well as elements that look like alerts but require different handling. There are also pages for experimenting with keyboard interaction, where key identifiers are shown for tooling verification.
Forms: Forms can be submitted using JavaScript, or form submission, and validation can be turned on and off. Explore fully.

We have pages for most fundamental web technologies.

Applications (Apps) (In-Depth Testing)

The “Apps” section features small, typically one-page applications designed for more in-depth testing.

Classic Exercises: A common example is the triangle application, often used to help explore testing principles, such as checking boundaries and functional requirements.
Interesting Exploration: Some apps do have bugs. Some have hidden features. They are all designed to be interesting to explore and automate.
Backend Interaction: Some applications use JavaScript or CSS, while others send data to a server. This includes API-backed forms (like a calculation form). I encourage you to use the network tab to observe requests and explore the underlying Swagger API, which supports POST and GET requests and can be integrated with tools like Postman or Bruno.

Advanced Practice and Resources

The “Challenges” are designed to be more difficult to automate, although they are generally easy for a human user to interact with. This section helps users test the full scope of their web automation tool capabilities.

I am building a reference section containing information related to testing. This goes beyond defining elements, explaining instead why elements are tested and outlining the risks associated with elements (such as input elements).

The reference section also provides links to various videos demonstrating exploratory testing in action.

Visit The Site

testpages.eviltester.com