Expert Take on Playwright, and API Testing with Bas Dijkstra

Foreign.

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

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 Boz 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 does like a Rest Assured C shop implementation that I think is really cool and just testing in general, especially training around testing and what things you need to know about if you don't know. Boz is an independent test automation consultant and trainer. He has a career spanning over, I think 17 years in the test automation field and he's contributed to software testing and automation solutions utilizing a bunch of different programming languages, frameworks and technology stacks. If you follow him on 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 for many companies across the world, both the 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's a known expert. And like I said, he's one of the main developers behind rest assured.net a library designed to really simplify the process of writing tests for HTTP APIs in C. Wish I had when I was working with C Sharp back in the day and I only had Java Rest. It should. All right, you don't want to miss this episode. Check it out. Apoz welcome back to the Guild.

Hey Joe, it's good to be back. It's been a while.

Yeah, it's been 2017, I think. It's been so many years, it's crazy.

Yeah, I was just. Look at seven years. Oh, wow.

Yeah, so good point. It's been seven years. Like what is new? I think that episode we did was on API testing and automated testing. So have you seen anything changed that you're like, wow, wow, things have changed since then.

Select 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 are, 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 marketing.

All right, so what hasn't changed then? So when you were talking about API testing, say seven years ago, are there still things that people may not get correct or they're not focusing on the right testing approaches with APIs?

Yeah, so 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 is what we do. A lot of it, unfortunately, 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 expected? And 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 bit on educating people about all the other things that you can do around testing, API testing over the last couple of years.

So, yeah, 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 than with APIs?

So that's a two part question. It's probably going to be a three, four, five part. So sorry about that for all those of you who are listening. First one, it is 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, still there's. And that's not necessarily with the Testament themselves, but maybe team leaders technically say, well, we just need to confirm that things work and then everything else we do through the graphical user interface 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, people don't worry about, they're not aware of all the other kinds of interesting testing things that you can do around APIs and it's just, well, is there ever enough time really to do things like this? I don't think so. And again it's over the last seven 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 HPE status code, 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.

So Bas, I love talking to folks like you because you've seen, you talk to a lot of people and you see a lot of different situations and a lot of companies. So over the seven years, have you seen API testing has become more difficult? Maybe because of, you know, 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 may be not going deeper?

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 perspective and we need to think a little bit. There's your API has users too and so we be. And that's something that I think can still be improved. That's just look at an API from an API user, an API consumer perspective and that's something that's.

Call it awareness, something that I think there's still room for improvement, room for growth there.

That's a great point. Because it's headless, you know, it may be an internal API that's used by your 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 it 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.

Exactly. So 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 just say, well, 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.

Word, but that's my next question. Perfect.

Yeah. Yes. But all. It just tells me a lot about the measure of the. The attention to detail and the attention to quality that developer, the API developers and designers took when they started writing the stuff. And it is 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 interfaces, including APIs as well.

So, Bas, you brought up a good point. You were talking about more exploratory testing and popped in my head was 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 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?

And 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 last. With the growth of the adoption of APIs. And APIs are all about data, and if there's anything that hackers are interested in, it's data. So. And that's probably why you see so many data leaks, hacks, whatever you want to call it, data exposures, because a lot of APIs are still unfortunately very, very vulnerable to these data exposure, to security vulnerabilities. So. And that's why I've 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 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, there's a lot. If you dive deeper, there's lots of the 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 at 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 given I am who I say I am, I shouldn't be allowed to see, for example, 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 again, once again, with tools like Postman and a little bit of creativity and using that API security, that OWASP top 10 as a guideline.

All right, Boz, I don't want to go on a rant here, but I 100% agree with you. I've been trying to push security. I had something called a Secure 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 tend to do not as well. Why is there resistance to. I think testers should be involved because I think they're the best people, they're the smartest, that the skill set goes into it. They don't need to be security experts. But for some reason there 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, you know, I mean, it's. You could help, right?

Yeah, no, definitely. And I think it is definitely an image problem, challenge, whatever you want to call it. That. 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. And they say, well, oh no, we have dedicated pemtest teams, dedicated security experts who do that stuff, who do vulnerability scans or audits. That's again, that's what I was looking for in every three months or so. And that's it. It's also in the. So I work with a couple of companies where I do some. Where I run some workshops as part of their traineeships. So that's. They take people right out of high school, university, college, and they maybe not high school, and they grow them into junior testers, automation engineers, as that's whatever you want to call it. Over the course of a couple of months to maybe one or two 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. So 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 why that 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.

All right, Boz, I want to switch gears. I have a feeling you're not as into tools as I am, but I'd like to talk about tools because I think as testers, ultimately you're going to have to use a tool. And one of them 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 Shop application and they wanted 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 Shop library? Did you create that?

Yes, I did.

Tell us a little bit more. What is that? What is Rest Assured? CSHOP Library?

Well, the name pretty much says it all. So, 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 used C for their software development, especially for the backend and their API development. And I happen to like the language a lot because I think it's very powerful language. And if you see how Microsoft has made the language evolve over the last couple of years, that's, it's. They've done some amazing stuff in that area. So of course because I got interested in automation, I got more involved in the C Sharp 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 are, there's one very popular HTTP library in the C space that's Resharp, which I think is a fantastic library, but it's more of a general purpose library. It's not something that's specifically targeted at writing tests, which Rest Assured in Java obviously is at the whole dsl. The whole API of the library itself is geared towards making it as easy as possible for you to write tests. So I couldn't really find something similar in the C Sharp space. I had a bit of time on my hands. I needed a. Or I was looking for a bit of 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 Project. The platform that's, that was owned by Tricentis, that's now unfortunately discontinued. So I developed some SDKs for them. So I got the hang of what it takes to build a release an open source library back then and I was looking for something similar and I said well, so I want to do some open source software development. I like C and I can't find an API testing library in the C Sharp ecosystem that has the same expression power as Rest Assured for Java. Why not create something similar to Rest Assured but in C? So 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 Johan who's the guy who 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 but for the C ecosystem? Because then explained, pretty much told him what I told you and he said oh, that's an absolutely great idea. So that's how it all got started really.

How hard was it to port over if someone's thinking oh, I can't do that because I thought this would be great And C Shop, but I don't have the skills to. And then you, like did it.

So it was actually a lot easier than I thought it would be.

Really?

Yes.

All right.

And that surprised me as well. If you look at the source code, sure, there's still lots of things that can be improved, but essentially that's true for Rest Assured in Java as well. It is a wrapper and 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 in System. Net HTTP, 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 restassured. 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 Rest Assured in Java is. And all 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. So I still learned a lot about the inner workings of HTTP and systemnet 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 DHCP client that's in the. NET Framework. Just makes it a little bit easier for you to use that.

All right, boss. So when would someone use this approach over a tool 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, like how do you know which tool to use or what technology to use?

Okay. Of course I cannot answer this question without saying it depends first.

Right.

You know that I have to. I'm sorry. So I love Postman, but where. I think at some point you'll run into the limitations if you want to run automation at scale. So 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 build larger automation suites, I think just 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 used to using, which is they do their stuff in code. So they are just a little bit further removed from using low code testing and automation tools like Postman. And also that's I think specific to Rest Assured. Net, which is something I. Well, 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 restassured.net 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. So you'll need to deploy that API somewhere first and really talk to it from an outside perspective. Whereas with Resident and with code based solutions you have this tighter integration with the API source code, for example.

That's so Boz. We're half hour into it, but we didn't even get to the main topic that I wanted to address.

Oh boy.

What caught my attention recently, like 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 Boz back on and talk about this. So since 2017, one thing that has changed and like I said, it's just tooling. Tooling is tooling. But playwright seems to really have 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? You know, those types of things?

That's the key thing. It is just me riding the popularity the playwright.

No, it is, I think it is. It's a very interesting tool and there's a lot of demand for it. A lot of people interested it. And I think that for people who are new to playwright, it would help them if they have a workshop that they can follow, that they can attend, that gets them Started writing playwright tests. So. And that's it, really. I want to. Again, I love Playwright and love the work that again, Microsoft is doing in this space, porting 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 for, can you run a workshop on playwright? I said, sure. And that was the trigger for me to start learning.

So these things happen more often than you think, by the way.

Right.

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. And. But also I wanted to give honest overview of Playwright. So you see all these Playwright is better than Selenium, Playwright is better, all these verses 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 space, obviously is Selenium and Cypress to some extent.

Yeah, absolutely. And I have to mention tools like WebDriver, IO and things like that. There's so many out there, I definitely.

Did not mention them on purpose. And I guess the webdriver is fantastic as well. It's just 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 wor. Cans of worms for me. But now I was just. I was raised on statically typed compiled programming languages, mainly Java. So it is JavaScript and TypeScript to a sort of kind of lesser extent. But it is. It's a different language with different mechanisms and some different principles, but fortunately also a lot. It's still object oriented programming. So a lot of the knowledge that add is easily transferred into that ecosystem.

Absolutely. So, Buzz, I definitely agree. I don't think there's one main tool. I think it's the right tool that works for your team. But obviously there's so many tools. You have to make a choice. You have to have some criteria. So how do you make a comparison with the tool, say playwright against something else without not bad. Melting another tool. How do you know 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.

Exactly. And that's the first point I tried to make. So I have my personal preferences, absolutely. But I try to leave those at the door when I come into a client. And 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 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 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 better than 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 into that one umbrella term which is called context. Context is super important and context involves technology stack, 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, many people who have tester on a LinkedIn profile or Estad or whatever. So 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 into 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 that you can't really go wrong with it. So there are no inherently bad tools out there anymore. Sure, 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.

So all right, but something has to explain the popularity of Playwright. Not just on popularity. If you look at GitHub stars like you see Playwright all of a sudden jump up and then Cypress and Slim. So not why is it better? But what are some features that make it stand out, maybe that maybe people are drawn to?

I think a lot of it has to do is that people compare it to Selenium. Typically, Selenium is a fantastic framework to send instructions to 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. So you have to add your own testing framework, like Junit Test in Java or Nunit in C, something like that.

People still think that you have to do all the browser and browser driver management in Selenium yourself. They obviously haven't been paying attention too much. Right. But that's still an argument that I hear surprisingly often, unfortunately. So I just wanted to put that out there. You don't have to do that anymore.

Absolutely. Selenium 4 changed a lot of things and that Selenium manager driver definitely helped.

It is, it's wonderful. Absolutely. But Playwright is an all in one framework, so it brings lots of features that Selenium out of the box doesn't have. So auto weighting 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 yourself. And Playwright is more like an all in one solution. It 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 Solani, you're 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 reason for the popularity of Playwright, the fact that it's just one dependency, one library, and again especially the JavaScript and TypeScript bindings because they have their own test run, our own search and library, everything. So that's, I think that's what people have been looking for, just a one stop shop, one library that is open source. So at no commercial license, no vendors, no nothing that gives them everything they're looking for. So 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.

Absolutely. All right, Baz, so I get asked 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, when someone's listened to this, like, oh my gosh, I'd love to get training from Baz. How do I do this? Is it something available to everyone? Is it just for corporates? Can they do it online? Do they need to be in the Netherlands? How does it all work?

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 said, unfortunately, I don't really, I can't really cater to that because. And you as a conference organizer, 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. So I strongly prefer the. For me, the easier 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 way is that it's really a collaboration. It's not, oh, we want an off the shelf training. Now I have a discussion with the company before to see, well, where are your 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 from 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 say, well, oh, this was fun. And I think a big part of that is because I can do the customization. I want to do the customization to improve the learning experience for these companies. So that's what I typically do. Many of my clients are in the Netherlands, but more and more of them are also abroad. So 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're 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 awesome.

I highly recommend people check out Boz. As I said, he's one of my Go to Resources for Automation okay Boz, before we go, is there one piece of actual advice you can give to someone to help them with their automation testing efforts? And what's the best way to find contact to or learn more about your training in general?

So the advice that I want to 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 programming, because they've been around for a long while and they without a doubt will be around for at least a while longer. So 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 and what it is that we're doing as testers, which is gathering information about quality and potential risks that are associated with software. So that's my advice if people want to get in touch. LinkedIn is a great way to do that. Or go to my website on Test Automation.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 with some new things into and create a course that's tailor made to your learning requirements.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode head on over to test guild.com forward/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. 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@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 software a problem for the Guild community. I'd love to hear from you. Head on over to test guild.info and let's make it happen.