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.

• https://podcasters.spotify.com/pod/show/spidey1944
• https://anchor.fm/s/1060f2ec0/podcast/rss
• https://www.youtube.com/@HowToTestThis
• https://www.linkedin.com/in/mamadou-ndiaye-consultant/

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

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

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

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

1. Risk-oriented approach: The podcast emphasizes the importance of understanding and managing risk in software testing.
2. 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”)

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

Career Background and Transition

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

Mistakes to Avoid in Testing

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

Learning and Development

1. Understand the underlying technology: Dissecting web automation tools like WebDriver and Playwright is essential for optimal use and test preparation.
2. Develop technical skills: Amplify testing skills and become a testers-programmer in your own right.
3. 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

1. Selenium introduction: Selenium is a library used to automate web browsers, providing a consistent API across multiple programming languages.
2. Selenium importance: It has influenced and helped define standards for browser automation, such as the WebDriver protocol and the bidirectional (BD) protocol.
3. 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.