Expert Take on Playwright, and API Testing with Bas Dijkstra

[00:00:04] Get ready to discover the most actionable end-to-end automation advice from some of the smartest testers on the planet. Hey, I'm Joe Colantonio, host of the Test Guild Automation Podcast, and my goal is to help you succeed with creating automation awesomeness.

[00:00:25] Hey, it's Joe, and welcome to another episode of The Test Guild Automation Podcast. And today, you're in for a special treat. We have Bas joining us to talk all about a bunch of different things in automation. He has running some awesome trainings like Playwright workshops, he has API testing updates with just like a REST Assured C# implementation that I think looks really cool and just testing in general, especially training around testing and what things you need to know about. If you don't know, Bas is an independent test automation consultant and trainer. He has a career spanning over 17 years in the testing automation field, and he's contributed to software testing automation solutions utilizing a bunch of different programing languages, frameworks and technology stacks, you follow him of LinkedIn. He's very helpful. He posts there all the time, so he provides a lot of test automation training also on a multitude of technologies from many companies across the world, both in Netherlands and internationally. And he has excellent reviews. If you ever go to his website, you'll see he's really well respected. I always, anytime he says anything on LinkedIn, I listen because he is a known expert and like I said, he's one of the main developers behind RestAssured.net, a library designed to really simplify the process of writing tests for HTTP APIs in C#, which I had when I was working with C# back in the day, and I only had Java REST Assured. You don't want to miss this episode. Check it out.

[00:01:49] Joe Colantonio Hey, Bas, welcome back to The Guild.

[00:01:52] Bas Dijkstra Hey, Joe. It's good to be back. It's been a while.

[00:01:56] Joe Colantonio Yeah, it's been 2017, I think. It's been so many years. It's crazy.

[00:02:00] Bas Dijkstra Yeah. It was just look at this, 7years? Oh, wow!

[00:02:04] Joe Colantonio Yeah. So good point. It's been 7 years. Like what is new? I think the episode we did was on API testing and automated testing. So have you seen anything changed that you like wow! Wow! Things have changed since then.

[00:02:20] Bas Dijkstra Like with so many things, yes, everything has changed. And then again everything is the same, still. So as you probably know, I am probably the world's worst technologist when it comes to trends and following trends and advising people on trends. So yes, of course, tools and techniques and patterns, they have changed. They've evolved. That's the word I was looking for. But then there are so many things that were true back then and that are very much true now still. So yes, lots of things to say. We have seen new tools, platforms, AI obviously is taking off majorly at the moment, but there's so much that hasn't changed all that much if you look behind the latest news and the latest market.

[00:03:15] Joe Colantonio All right, so what hasn't changed then? So when you were talking about API testing, say 7 years ago, are there still things that people may not get correct or like they're not focusing on the right testing approaches with APIs?

[00:03:28] Bas Dijkstra Yeah. I still see and it's definitely changed if we compare this to like 7 years ago, where nobody was really doing a whole lot of API testing, it's definitely gotten better. So there's more and more people that I meet that I talk to, that I get in workshops that say, well, we know a little bit about API testing and this what we do, a lot of it unfortunately, is still pretty superficial. And by superficial, I mean there's lots of people still using a single tool to craft some requests, send those requests and then check. Well, is it returning the expected HTTP status code? Is it returning the data that I expect. And then they pretty much that's what they do. And that's a good start. It's a very good start, but there's so much more to explore in the realm of API testing really, which is why I've been trying to do my bits on educating people about all the other things that you can do around testing API testing over the last couple of years. So yeah.

[00:04:38] Joe Colantonio So I guess two part question, why do you think it's somewhat superficial? Is it just people are too busy or is it more education or is it more they're just doing what they need to do. And the second part is, what more can they be doing and what the APIs?

[00:04:54] Bas Dijkstra That's a two part question. It's probably going to be a 3 or 4 or 5 parts. So sorry about that for all those of you who are listening. First one, it is a not a but maybe there could be better content out there that teaches people more than just confirming that something works. So that's one. It's not a lot of time, maybe so unfortunately. And that's not necessarily with the testing does themselves, but maybe team needs to take and say, well, we just need to confirm that things work. And then everything else we do through the graphical user interface add to see what the end user is seeing, for example, so it doesn't get the love and attention that I think it should get for those reasons, and people don't know that they're not aware of all the other kinds of interesting testing things that you can do around APIs, and it's there ever enough time really to do things like this? I don't think so. And again, it's over at 7 years that was true when we spoke the previous time. I think it's all about shipping fast and shipping often. So and a lot of focus is on confirming that things work. And that's true for software in general. And that's very, very true if it comes to testing API, just write some tests that again confirm HTTP status code, confirm at check that data. It looks like the data that you expect. Maybe if you're lucky, do some schema validation. And that's pretty much it.

[00:06:37] Joe Colantonio So that's I love talking to folks like you because you've seen you talked to a lot of people and you see a lot of different situations and a lot of companies. So over the 7 years, have you seen API testing has become more difficult, maybe because of the buzzword, everyone's moving to the cloud, becoming cloud native, and now they may be using an API that's outside their control. Does that make it harder than to test and why people maybe not going deeper?

[00:07:03] Bas Dijkstra I don't necessarily think it has been more difficult, if anything, because there's been more content and more attention to API and the tooling has improved. I think it has gotten easier or the barrier of entry to get into API testing has become a lot lower, and that's obviously a good thing, but there's still a lot of people and we look at software mostly from an end-user's perspective, and we need to think a little bit. Your API has users too. And that's something that I think can still be improved. That's just looking at API from an API use or an API consumer perspective. And that's something that's maybe we call it awareness something that I think there's still room for improvement, room for growth there.

[00:07:59] Joe Colantonio That's a great point because it's headless, it may be an internal API that's used by application and people may not know that, hey, this is still being consumed by another team or another part of the application. Let's treat as if I'm a user of it, not just it's like something under the covers that no one really cares about, I guess.

[00:08:16] Joe Colantonio Exactly. One of the things I typically start out when I start talking about API testing is just exploratory testing. There are so many wonderful and interesting things that you can do just by using tools like Postman or whatever, and a little bit of creativity and critical thinking, which I think is what we do best as testers. And so, Hmhm API spec says that if I submit this, it will react this way. Let's find out what happens if I create a request with some data that's outside of the spec. That's considered invalid by the spec, because that tells me, as a tester a lot about A, how secure an API is. I'll talk about API security testing in a little bit more detail in my work.

[00:09:13] Joe Colantonio That's my next question. Perfect.

[00:09:15] Bas Dijkstra Yeah. Yes. But all it just tells me a lot about the measure of the attention to detail and the attention to quality that the developer, the API developers and designers took when they started writing this stuff. So a lot of the things and techniques that we've been using as testers for the last couple of decades really against the graphical user interface, against that one interface in an application that's written to be consumed by human beings. A lot of that translates to other kinds of the phases, including APIs as well.

[00:09:51] Joe Colantonio So Bas, you brought up a good point. You were talking about more exploratory testing and popped my head with security. Then you mentioned security. I've spoken to a lot of people on my DevSecOps podcast, and I'm surprised about the amount of hacks that happen at the API level. And I wonder if it's because people, because they think like it's not seen by anyone, that they don't realize that it's probably really more vulnerable. But can you talk a little bit more about why security at the API level is so critical?

[00:10:18] Bas Dijkstra These are not my statistics, but I think it was 2023 or 2022, about 83% of all the traffic over the internet is through APIs and API traffic. Because it's often HTTP is pretty easy to detect and to capture and also pretty easy to exploit. So it's an attack factor that's become much wider in the loss of with the growth of the adoption of APIs and APIs are all about data. If there's anything that hackers are interested in, it's data. And that's probably why you see so many data leaks, hacks, whatever you want to call it and data exposures, because a lot of APIs are still unfortunately very, very vulnerable to these data exposures to security vulnerabilities. And hat's why I've had over the last six months to maybe a year or so, I've been diving deeper into the whole API security testing thing. And one of the things that I keep telling others as well, and it is the one thing that I've learned, is I always saw security testing as some kind of niche activity that can only be done by specialists who have deep technical understanding of all these specialized security testing tools and techniques. But that's not true. Sure. And there is a lot of if you dive deeper, there are lots of deep technical skills you can employ to find all these very interesting vulnerabilities, but there's a lot that you can do. Again, just by using common tools and some common sense, common knowledge, and a little bit of creativity as well. So if you look at the OWASp API Security Top 10, which is again the top 10 API Security Philippines, a lot of these things you can test for, you can start to explore with again, just tools like Postman and say, well, is this API exposing data that's given I am who I say I am? I should be allowed to see, for example, I shouldn't be allowed to modify, which is even worse. So it's one area of API testing that I've been doing a lot of reading and watching videos and trying stuff out over the last couple of months, and that's the message I try to get across to lots of other people in the testing space as well, is that you don't have to be this security expert to start testing for the security. If there are any security vulnerabilities in your API, there's lots of valuable information that you can uncover. And once again, with tools like Postman and a little bit of creativity and using that API Security OWASPs top 10 as a guideline.

[00:13:24] Joe Colantonio Bas, I don't want to go on a rant here, but I 100% agree with you. I've been trying to push security. I have something called a Security Guild, which is just a two day event dedicated just to security testing, and I tried running it for a few years and it bombed. And all my podcasts around security tended to not as well. Why is there resistance to. I think testers should be involved, because I think that the best people, that the smartest that the skill set goes into it. They don't need to be security experts. But for some reason that seems to be resistance to the idea of, hey, you can also help with security testing. Not this weird team that no one ever sees called security. It's like, I mean, it's you can help, right?

[00:14:03] Bas Dijkstra Yeah. No, definitely. And I think it is definitely an image problem, challenge, whatever you want to call it that's still with that grew over the years and that's unfortunately still with us, which means that a lot of testers don't really get exposed to security. They said, well, oh no, we have dedicated Pen test teams that accredited security experts who do that stuff, who do vulnerability scans or audits. That's what it was looking for in every three months or so. And that's it. I work with a couple of companies where I do some where I run some workshops as part of their traineeships. They take people right out of high school, university, college and maybe not high school, and they grow them into junior testers, automation engineers, SDETs whatever you want to call it over the course of a couple of months to maybe 1 or 2 years. When I see their program, their curriculum, I'm happy that there's a lot of things about testing and automation and API. There's not a lot of talk about security. I think it's still somewhat of a blind spot, maybe, for a lot of people, for a lot of companies. I don't know exactly what it is, to be honest. Maybe it is because people, there's lots of people who still think that it's something that you need deep technical skills for, and at some point, you will need to do that. But again, there's so much you can do with common sense and a bit of creative, especially at the API.

[00:15:57] Joe Colantonio Yeah. All right, Bas, I want to switch gears. I have a feeling you're not as into tools as I am, but I like to talk about tools because I think as testers, ultimately you're gonna have to use a tool. And one of the I just want to get a shout out for is, REST Assured, I used to use the Java implementation back in the day, and we had a C# application. They want to use REST Assured. And we couldn't. But I believe you came. Are you the one that came up with REST Assured the C# library. Did you create that?

[00:16:23] Bas Dijkstra Yes I did.

[00:16:25] Joe Colantonio Tell us a little bit more. What is that? What is REST Assured C# library.

[00:16:28] Bas Dijkstra Well, it's the name pretty much says it all. Like you, I've been a fan of REST Assured for a long while now, and over the last couple of years, I found myself working with more and more clients who use C# for their software development, especially for the backend in their API development. And I happen to like the language a lot because I think it's a very powerful language. And if you see how Microsoft has made the language evolve over the last couple of years, they've done some amazing stuff in that area. I've got it because I got interested in automation. I got more involved in the C# ecosystem. And of course, I do quite a bit of work and training around APIs. I started looking for a library that was similar to REST Assured, but in the C# space. Now, there's one very popular HTTP library in the C#'s space that's Rest#, which I think is a fantastic library, but it's more of a general purpose library. It's not something that's specifically be targeted at writing tests, which, REST Assured, in Java, obviously is, and the whole DSL. The whole API of the library itself is geared towards making it as easy as possible for you to write tests. I couldn't really find something similar in the C# space. I had a bit of time on my hands and I needed a or I was looking for a bit of a program software development challenge because, well, there's a lot to learn in that area as well. And a couple of years earlier I did some similar projects for test projects. The platform that was owned by Tricentis that's now unfortunately discontinued. So I developed some SDK for them. I got the hang of what it takes to build a release in the open source library back then, and I was looking for something similar, and I said, well, hmmm. So I want to do some open source software development. I like C# and I can't find the API testing lively in the C# ecosystem that has the same expression power as REST Assured for Java. Why not create something similar to REST Assured but in C#. I've been in touch with the developer who started REST Assured, so I know it's pretty big and there's so many contributors now, but I reached out to you. I originally created, REST Assured back in 2010. He's still working on it, by the way, and I asked, well, hey, what do you think IF I created a port of REST Assured path for the C# ecosystem because of that explained pretty much told what I told you not. And he said, oh, that's a absolutely great idea. That's how it all got started, really.

[00:19:28] Joe Colantonio How hard was it to port over if someone's thinking, oh, I can't do that because I thought this would be great in C# but I don't have the skills to. And then you like did it.

[00:19:37] Bas Dijkstra It was actually a lot easier than I thought it would be.

[00:19:42] Joe Colantonio Really?

[00:19:43] Bas Dijkstra Yes.

[00:19:45] Joe Colantonio All right.

[00:19:46] Bas Dijkstra And that surprised me as well. If you look at the source code, sure, there are still lots of things that can be improved, but essentially, that's true for REST Assured in Java. It is a wrapper, an abstraction library on top of the native HTTP libraries of, well, Java for REST Assured, and in my case for C#, it's a wrapper around basically the HTTP client and system.net.Http is, which is native to the .Net framework. And I don't want to downplay the library itself or anything, but it's pretty much that's what it is. An abstraction layer on top of stuff that's already there in the first place, and that's doing a great job in the first place. So I could just not use REST Assured .Net and just use the Http client that's built into the .Net framework itself. You would just have to write more code and do a little bit more low level stuff yourself, especially if you're working with cookies, for example, those kinds of things, or form data, stuff like that. And all the REST Assured in Java is and all the REST Assured, .Net in C# is it's just an abstraction layer on top of that. Abstracts away all the boilerplate and leaves you with a human readable API, a set of methods and classes that makes it easy to write these tests. I still learned a lot about the inner workings of HTTP and system net HTTP and all those kinds of stuff. But if you have a good look at the source code, you'll see it is definitely not rocket science. It's just a little tool that helps you use the power of the HTP client. That's the .Net framework just makes it a little bit easier for you to use that.

[00:21:37] Joe Colantonio All right, Bas, when would someone use this approach over like a two more like Postman. Is it more like this is a programmatic type of approach. And Postman would be more of like I don't know what like how do you know which tool to use, what technology to use?

[00:21:51] Bas Dijkstra Okay. Of course, I cannot answer this question without saying it depends first. You know that I have to. I'm sorry. So I love Postman, but where I think at some point will run into the limitations if you want to track automation skills. I love Postman for exploratory testing. I don't think there's a tool that does or that facilitates exploratory API testing better at the moment than Postman does, but at some point, if you want to scale or build larger automation suites, I think adjust the way Postman does its versioning, does its integration with CI is a little bit clunkier, and also a little bit further removed from what the API developers are already uses, of which they do their stuff in code. They are just a little bit further removed from using low code testing or automation tools like Postman. And also that's I think specific to REST Assured . Net which is something I love. It is not in it's for example, if I want to test an ASP.Net API, the way these they come with their own, they deliver their own HTTP client, which is. And then you need to use that to invoke the service if you want to run tests against it. With REST Assured that I can just plug in that HTTP client, say, well, instead of the HTTP client that you create yourself, now use the one that's given to you, that's delivered to you by the API that you're testing, which is something that with Postman is just impossible. You need to deploy that API somewhere first and really talk to it from an outside perspective. Whereas with REST Assured and with code based solutions, and where you have this tighter integration with the API source code, for example.

[00:23:59] Joe Colantonio Bas, half hour into it. But we didn't get to the main topic that I wanted to address.

[00:24:04] Bas Dijkstra Oh boy!

[00:24:06] Joe Colantonio This come to my attention recent. This is all awesome stuff. That's why. But what originally caught my attention when I had contact you was I did a news show and you had posted something about a Playwright workshop, and it got like a lot of people clicking on it, and I'm like, oh, I need to get Bas back on to talk about this. So since 2017, one thing that has changed, and I like I said, it's just tooling. Tooling is tooling. But Playwright seems to really been gaining traction. So you posted something about having now a workshop for Playwright. Can we just talk a little bit more about like why this workshop? Why Playwright? Is there a growing demand? Those types of things.

[00:24:43] Bas Dijkstra That's the key thing. It this just me writing the popularity in the Playwright. I think it's a very interesting tool and there's a lot of demand for it. A lot of people are interested in it. And I think that for people who are new to Playwrights, it would help them if they have a workshop that they can follow that they can attend that gets them started writing Playwright tests. That's it really. I want to again, I love Playwright. I love the work that, again, Microsoft is doing in this space supporting and backing Playwright. And well, as we've all seen, it's becoming incredibly popular ever since it was launched. I think like three years ago at the time of recording, obviously. So first of all, I did again, this is just me playing into demand. I got asked, can you run a workshop on Playwright? I said, sure. And that was the trigger for me to start learning. These things happen more often than you think, by the way. And not just with me. I know from other trainers or workshop facilitators that's exactly the same thing. Oh, someone asked me a question. Time to start learning it. But also I wanted to give honest overview of Playwrights. So you see all these Playwright is better than someone. Playwright is better-all these versus kind of things. I don't think it's really fair. So I wanted to create a workshop that A, gives people a solid introduction into Playwright, but also provides a fair comparison between Playwright and the alternatives out there, which mainly in the open source phase, obviously, by Selenium and Cypress to some extent.

[00:26:41] Joe Colantonio Absolutely. And I have to mention tools like WebDriver.IO and things like that. There's so many out there.

[00:26:46] Bas Dijkstra I definitely did not mention them on purpose and I got to do better every year. It's fantastic as well. I'm not using that as often because until recently I've managed to sort of kind of avoid the whole JavaScript TypeScript ecosystem. But even that it has changed, especially over the last couple of months, again, because of the growing popularity of Playwright. And a lot of people use Playwright with TypeScript. So that has pushed me into that area as well, which is opening all different kinds of words for me, but now I was just I was raised on statically typed compiled programing languages, mainly Java. So it is JavaScript and TypeScript to a sort of kind of less of extent. But it's a different language with different mechanisms and some different principles, but fortunately also a lot. It's still object oriented programing. So a lot of the knowledge that I had is easily transferred into that ecosystem.

[00:27:54] Joe Colantonio But absolutely. Bas, I definitely agree. I don't think there's one main tool. I think it's the right tools that works for your team. So but obviously there's so many tools you have to make a choice. You have to have some criteria. So how do you make comparison with the tool, say Playwright against something else without badmouthing another tool? How do you know like how to choose a tool then without correctly then, without saying, oh, this is better, it's not better. It's better for us because not because it's better than.

[00:28:23] Bas Dijkstra Exactly. And that's the first point I try to make. And so I have my personal preferences. Absolutely. But I try to leave those at the door when I come into a client. I have to admit, I don't always succeed in that especially if it involves tools that I created myself. But I try to be as objective and open as possible, because in the end, I'll probably be with working with that team or that company for a couple of days to maybe a couple of months. But they have to live with the consequences of the choices that we're making together for a long time coming, which means it's probably also in my best interest. If they make a choice, that's the best fit for them. And that's back nicely into what you just said, is there's no such thing as one tool is better than the other, or one tool is the best tool, which, if you look at my probably your LinkedIn feed as well, is nonsense, because obviously tool X is better than tool Y. And then for someone else, tool Y is a million times better than tool X. But it is about finding the best fit for a team. And that depends on lots of things that for me, all fall on into that one umbrella term, which is called context. Context is super important and context involves technology stack of what you're actually testing, trying to test. What's the information, what's the skill set of the people who are going to work with the tools, who will be doing the heavy lifting in writing, running and maintaining the test? And also, is that going to be mainly people who have developer on their LinkedIn profile, maybe people who have tested on a LinkedIn profile or SDET, or whatever. All of these things play a role into finding out what would be the best fit for a team or a company. Often they've already made a choice, and they just bring me the say, well. We just want some confirmation from someone from the outside that we made the right choice. So it's more like validating their choice rather than help them picking something. But yeah. And so one thing I start with pretty much is that you can't really go wrong with. There are no inherently bad tools out there anymore. Sure. As some tools might be a bad choice for your context, for your situation, for your team organization, the skill set. But there are no inherently bad tools out there anymore.

[00:31:12] Joe Colantonio So all right, but something has to explain the popularity of Playwright. Just on popularity. If you look at GitHub stars like you see, Playwright awesome jump up and then Cypress and Selenium. So not why is it better? But what are some features that make it stand out, maybe that maybe people are drawn to?

[00:31:30] Bas Dijkstra I think a lot of it has to is that people compared to Selenium, typically. Selenium is a fantastic framework to send instructions through a browser and get feedback from a browser and inspect that feedback. There's lots of stuff in Selenium that you still need to do yourself, or that you need other tools for to do for you. And say, you have to add your own testing framework, like JUnit to test the Java, Nunit, and C#, something like that. People still think that you have to do all the browser, browser driver management and Selenium yourself. They obviously haven't been paying attention too much. But that's still an argument that I hear surprisingly often, unfortunately. I just wanted to put that out there. You don't have to do that anymore.

[00:32:19] Joe Colantonio Absolutely. Let me fortune's a lot of things. And that Selenium manager driver definitely helps a lot.

[00:32:26] Bas Dijkstra It's wonderful. Yeah, absolutely. But Playwright is not all in one framework. So it brings lots of features that Selenium out of the box doesn't have. So auto waiting and synchronization which all of these things that Playwright does you can do or you can add to Selenium, but you have to do the work itself. And Playwright is more like an all in one solution that happens to do things in a very solid manner. The only thing that I want people to be aware of is that the fact that Playwright brings its own modified versions of browsers, and with Selenium here actually invoking testing against proper browsers that you install and manage yourself on your system. But I think that is for me, for what I've seen, the biggest the reason for the popularity of Playwright, the fact that it's just one dependency, one library that, again, especially the JavaScript, TypeScript bindings because they have their own test runner own assertion library everything. That's what people have been looking for, just a one stop shop, one library that is open source. So no commercial license, no vendors, no nothing that gives them everything they're looking for. The browser management, native support for parallel execution. It's fast. It does auto waiting. And you have these nice features like tracing and debugging and all that stuff which you can all add to your framework yourself if you're using other libraries. But why do that if you've got a library like Playwright that happens to bring it all to you, just happens to give it all. Give that all to you for free, basically.

[00:34:21] Joe Colantonio Absolutely. Okay Bas, I could ask for training all the time. Or I want to learn this. I want to learn that. You have a bunch of workshops. So could you explain a little bit more about your workshops, like say, if someone's listen to this, like, oh my gosh, I'd love to get training from Bas. How do I do this? Is it something available to everyone? Is it just for corporates? Can I do it online? Do they need to be in the Netherlands? How does it all work?

[00:34:41] Bas Dijkstra So the answer to that is not a simple issue. So first of all I am sort of kind of lazy in that I get quite a few requests from individuals for training and then so but unfortunately, I can't really cater to that because and you as a conference organizer, and you're probably familiar with that, setting that up, managing that, doing all the marketing and all the admin and all that stuff yourself is a lot of hard work. I strongly prefer the. For me, the easy route is a company that contacts me and say, well, I have a group of people. That I want trained in a certain subject. Can we bring you in? Then, it's pretty much always. Yeah. Of course. Let's talk. Of course, it depends a little bit on the topic, but because I've been doing this for a while. I've got a pretty extensive library of exercises and material that I can pull from. Also, what I love about working this is that it's really a collaboration. It's not all we want an off the shelf training. I have a discussion with the company before, obviously. Well, where are you people now? What do they want to learn and where do you want them to be after this course, which is and yes, that involves a bit of customization for my end and some extra time invested probably. But it almost without exception, leads to a much higher satisfaction and a much better reviews, which then in turn is good for me as well. At a later point in time, because, well, people talk to one another and they, they said, well, oh, this was fun. And I think a big part of that is because I can do the customization, and I want to do the customization to improve the learning experience for this company. So that's what I typically do. Many of my clients are in the Netherlands, but more and more of them are also abroad. Travel obviously over the last couple of years hasn't really happened all that much, both because of the whole Covid thing, but also because of me having a family with young children. They are getting a little bit older now and it gets easier to do a little bit more traveling so I can say yes to more opportunities abroad as well, which I think is just a fantastic perk of the job and a privilege, absolutely.

[00:37:08] Joe Colantonio Awesome. I highly recommend people check out Bas as this is one of my go to resources for automation. Okay, Bas, before we go, is there one piece of actionable advice you can give to someone to help them with their automation testing efforts? And what's the best way to find contact you or learn more about your training in general?

[00:37:25] Bas Dijkstra The advice that I will give is sure. Keep an eye on latest trends, but also don't forget the fundamentals. Study the fundamentals no matter if that's fundamentals in testing and testing approaches and techniques or fundamentals as in the pillars of object oriented programing because they've been around for a long while and without a doubt will be around for at least a while longer. It's always good to sure try that new tool, try that new technique, try the new large language model, but also keep an eye on the fundamentals of what it is that we're doing as testers, which is gathering information about quality and potential risks that are associated with software. That's my advice. If people want to get in touch, LinkedIn is a great way to do that or go to my website ontestautomation.com and you'll find an overview of everything that I do my blog, but also an overview of the training courses that I offer. Again, I want to say that what you see there is just an impression of the things that I do, especially if it's in company in house. I'd love to have a conversation to see how I can tailor that and mix and match the things that I've done, maybe put some new things into and create a course that's tailor made to your learning requirements.

[00:39:01] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguild.com/a493. And if the show has helped you in any way, why not rate it and review it in iTunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe, my mission is to help you succeed with creating end-to-end, full-stack automation awesomeness. As always, test everything and keep the good. Cheers.

[00:39:37] Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps, and automation professionals in the world, we'd love to have you join the FAM at Testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real-world value that can improve the skills or solve a problem for the Guild community. I love to hear from you head on over to testguild.info And let's make it happen.