Meet JASON HUGGINS, The Genius Behind Selenium!

In a land of testers far and widely journey seeking answers, seeking skills, seeking a better way. O the Test Illumination Testing podcast. Guiding testers with our nation awesomeness. From ancient realms to modern days, they lead the way.

Oh.

The Testicle Ovation Testing podcast.

Hey, welcome to another episode of the Test Guild Automation Podcast. This week, in honor of Selenium Conf happening in Valencia, Spain, I'm taking things way back, back to 2017. I'm re releasing an interview I did with the creator of Selenium himself. Jason Huggins. Recorded live at Selenium Conf that year. Now full transparency. This was actually the very first in person interview I ever recorded. And for reasons that now seem ridiculous, I picked one of the noisiest spots at the venue to do it. I even got comments like, why would you interview him there?

Fair question.

But thanks to the magic of AI, I've cleaned it all up using an audio enhancer tool that stripped out most of the background noise. So now you can finally hear Jason in all his audiophile glory as he shares the origin story of Selenium. His even dives into the early rise of automation and robots. You don't want to miss it.

Check it out. Could just tell us like why you created Selenium. What was your thought and did you ever think it get as big as it actually got?

Right. I mean, so it's, it's, it's. How much do you have? Right. So I, I have no short stories. So when we. So I was the tech lead on this project and Jim Evans at the Saucecon this week gave a couple of a version of it. It's mostly, mostly correct. Um, but what came down to I was a tech lead on a project, so we had 10 or so people working. We're working on an internal time expense tool. And the, the mandate for this was it was had to be fast because if you're a consulting firm, really your only internal system that you care about is the billing system so you can get paid. And at the time the company I was at, ThoughtWorks, they were expanding globally. It used to be just Chicago, but then they were expanding in England's and India and whatever. So all of a sudden the latency, that was fine. That local area network in Chicago, all of a sudden it was a huge problem when people from London were connecting to the Chicago system. So the current system was like super slow. So it had to be fast, fast, fast. That sets the context for why, for details I, I did later. So this is actually 2003, 2004, still actually kind of in like the dot com nuclear winter, there wasn't a lot of budget to do really anything. But we had basically people threatening me in London and India just over latency to like Chicago headquarters. So that, that's kind of, that sets the scene. So hey, it's 2003, 2004. Let's do this web thing, right? You know, it's been around for a while. Let's. So the previous app was a Lotus Notes app. We're going to do a web app, right? Very specific thing though when it gets actually, you know, fast forwarding to Selenium. We wanted to, in a, in a time, in a timesheet or a billing kind of context, we want to have this little web form and we wanted to have, if you had more than 10 items in your expense report or whatever, you wanted to add a row. The state of the art in a web app would be to like send that whole thing to the server. Server will do all the rendering, adding rows to HTML tables and send it back. But I knew with like a whole couple hundred consultants that's going to be a high latency, it's not going to be fast, right? So I had this idea like wait a second. Actually if you go into this, this JavaScript thing, like you can, you can modify the web page like add, you can change the page however you want and you can avoid a trip to the server. It's awesome. The downside is at the time JavaScript was super flaky and inconsistent between all the different browsers. So we had very strong discussions amongst the other engineers where it's like you shouldn't use JavaScript. JavaScript is. Using JavaScript is a career limiting move. It is a bad idea and you're a bad person and you should feel bad using JavaScript. This is like 2030 4400. That's 2004, right? So we actually I, I let them win the argument for a month. We re architected so everything went to the server and came back. And then it, of course it was slow. It's like no, screw it. So we put in the code to add, just like to dynamically add a row to your expense report and. But then as it proved out to be it, we had, I called like the sine wave equality where what happened was it would work in an explorer one week and then someone would change something. All of a sudden it would now be working in Firefox. This is actually pre Firefox 1.0. So this is like Firefox 0.9 Mozilla was a browser at the time, so it would be, they would be, it would be working in Firefox but they would accidentally break in ie. Of course they didn't test it in IE because their personal browser was Mozilla or whatever. And so every other week it was like working in one of those browsers. So it's like that was annoying. That was like requirement number one. Like okay, I want to, I can't get them to test all the browsers all the time, every time they touch something. So I wanted, I want to test two browsers. It was also knowing that just things were breaking that were working yesterday. So I want something as kind of like a regression, kind of a check before they push. I implemented this one rule of like there has to be at least one functional test for whatever you do before you put it in production. Anyway, so I wanted to have the test. So. And it was frustrating and in that context of the state of the art, whether it was open source or commercial tools, because everyone considered JavaScript a horrible bad idea. The open source tools you could only ever do like regular expressions on like the HTTP response, like the text. Mechanize is a very popular tool and all it did was do assertions on the text response. It didn't assume you'd be doing assertions on the browser. The rendered page and the commercial tools would. Because, you know, Microsoft had like 95% market share. Why would you test any other browser, like had other conversations about that? Why would you care about two browsers? That's pointless. A bunch of hippies care about the other stuff. Oh, and that Apple thing, Apple's dead, right? I mean again, this is the world. People don't realize that but right. What JavaScript limiting move. Apple. Yeah, that's kind of, that's cute. But like we don't do video processing. We don't do, you know, whatever.

But we were like a trend setting consulting company. So we had, everyone had MacBooks and stuff for each other tomorrow and everyone was using Mozilla, whatever. So. So I didn't want to create a testing tool. Sorry again, long story, sorry.

And we sought out other open source tools. The closest was the JS unit. So JavaScript unit. Like it was in a browser kind of rendering stuff. But it was very unit test focused, not functional test. Like it didn't know how to go from page to page to page, just in one page. Also there was another one.

HTML unit was a Java project and it kind of, it was like a headless browser. It had a kind of a JavaScript thing, but it wasn't real browser, so it. It. You couldn't tell if that matched a real browser experience. Right. So again, like the requirement was two browsers. Like one test drive, two browsers. And assuming you're going to be interacting with some kind of JavaScript app and doing an assertions. Like after JavaScript did something interesting. So there was really nothing. Um, so I actually took a break from the project I was leading kind of to start a side project. We kind of, you know, found a conference room and just like disappeared for a month. It was me and like two other thought workers, Paul Gross and then Gina.

Sorry, G. Tina. She goes by Tina Wang. There's the three of us working on a month for like a month on this first thing. Yep. And then we had it and the people came by. I actually thought we were going to be famous for this Time and Expense app that we were making as it was super, super cool. That's a whole other story where we like evaluated all the time and expense things that were out there. Of course, like, you know, big surprise for a consulting firm. We did a review of all the packaged apps and we came with the expert decision that we were going to have to write it a custom package ourselves. But I really thought that the time expense thing was going to be interesting. But people came up to me after, like, after we got it up and running, we had the IE tests and the Mozilla Firefox tests. It was actually fun to watch. Right. Turn on the monitor, see it go. No. Like a lot of people, I hadn't like really kind of seen that kind of. It's kind of fun. It's really fun.

It is.

Sometimes when I'm in my. It would be running on the computers in my office and I would forget that it's at the top of the hour. I would. It's kind of like a poor man's poor person's CI system where you just like link it to a batch file, schedule it to run at the top of the hour. And sometimes I forget, it's kind of like Big Ben, you know, blasting. All of a sudden I hear this clicking from the computer. The monitor would be off, but IE sends when you click. Whatever. Too long of a story. But people would come and ask me about our testing tool. I wanted to talk and pivot to Time Expense app. Super, super cool. This is just one part of it, so I think. Answer your other question. I think I realized it was like a thing when I got. When I kept on getting more questions about it. I Think we're completely unsolicited. I started getting invitations to talk about it at other places. Like other consultants at thoughtworks were another people in London and whatever were telling their clients about it.

Oh, cool.

That was actually one of the things that made it easier. It was easier to open source it, to get it to our clients. Some of them had really weird procurement policies. So it was easier just to open source, download it as opposed to negotiate some kind of agreement. So once it was kind of out there, people would start using it and start having questions. And then it just kind of took on a life of his own. Anyway, super long story. Oh, very cool.

No, that's awesome.

It came from a very technical thing. I didn't want to test create a testing tool, but it like fell into it. I didn't know at the time there was a testing industry, there were books, there was like, you could have an entire career. It was just like this annoying problem where JavaScript was like, bumming me out.

Yeah. So you have a problem, you scratch your own itch, and all of a sudden it's. A lot of people have really benefited from it.

Right. Sorry. It's super lucky. No, it's cool.

So it seems like your vision keeps getting bigger and bigger. So you just start off like testing an app and then creating an app that. That tests it. And then all of a sudden you get into cloud once again. Early 2008, I think it's really early. Was it 2008 for Sauce Labs?

Yes. Found it. So Selenium was the very first release of Selenium was like first beta, or what do you want to call it? First prototype. It's like April of 2004. It was actually, I think, formally released as a project like fall 2004. And we founded Sauce Labs in July of 2008. So. And before that, I left ThoughtWorks to go to Google. And so I've been accused of planting the seeds of a problem. And whatever I create, it causes. It solves a problem. It creates a problem. Right, right. And so the next problem, now that you can test in every browser, the problem is running a lab of all these browsers. Like, so if you have a hundred machines, half of them are arbitrarily, half of them are ie, half of them are Firefox. What if, you know, then Safari comes out or Krone comes out, like, do you buy more machines? Do you split your lab? Like, that's the job. Right. There were precursors to that, I think I noticed. So it was project when I still have thoughtworks it was the developers were threatening mutiny because the build was taking 20 minutes. I mean it's a pretty simple like leap of like, okay, these guys are like about to like not care about testing at all. But it comes down to like it's 20 minutes. Like, well, how many tests do we have? Like it's running on the machine. Like what if we got four machines? What would happen? Right? So what do you know? Magically the build took five minutes and it was like high fives all around and they're like, this is awesome. Like, wow, that's weird. I went, I wonder how, I wonder if that is unique to just this group of people. It probably isn't, right? So I think right around that time a lot of people were realizing like, oh yeah, having lots of selenium tests, if you run a hundred sequentially on one machine kind of bums you out. So a lot of people started were dabbling with like kind of making a grid. Before the word cloud was a thing. There's various conferences, but one of them was kitcon is the name of a conference, so Continuous Integration and Testing conference. The first one was in Chicago and it was I think like 2006 and people like footnote to history. People don't remember this but sun was arguably the first cloud computing company. No one remembers this but they had this thing, they called it grid computing and you could rent their machines in the, or whatever in, in the network, whatever. They didn't call it for like a dollar a minute. But the thing was when I was like looking like, oh man, how do I just get like, like quick disposable access to a bunch of machines in like 2006 or 2005? Um, so I remember at, at that kick on conference, like I think this like grid computing thing, I think it's totally a thing. I think it's a little too expensive. Like the dollar a minute thing is way too weird and you have to like wrap it up in a batch file and then email it to them or FTP. It was clunky. And then like a year later EC2 comes out, Amazon Elasticute Cloud and it's 10 cents a minute instead of a dollar. And then all of a sudden it's, it was, for me it was the same idea. It was like, oh, way better pricing and then you get full like shell access to the thing. So that's even better. But at that time I was at, now at, at Google they had the same problem. The rightly team had an hour long build and they're running it in two browsers. And someone at Google had also really an idea like hey, what if we distribute the machines? So it's one of those things that like so true about all inventions. They're almost always invented simultaneously on two different corners of the planet. And it just comes down to a race to whoever can kind of get it done and out the door and tell more people the fastest. But I ended up at Google and then worked on the Slang Farm. This became this. It started with the rightly team which is like now Google Doc. It became this virtuous cycle where the more people internally at Google heard about this. Wow. They went from an hour long pills to a couple of minutes. The more teams wanted to be part of Selenium Farm, which means then we had more budget to add more machines. So it became this huge thing where we kept on adding machines and adding more clients. So that was at Google. But the problem is like well, who besides Google can just have thousands of machines or whatever except for Amazon's EC2. And skipping ahead. Met my co founder at Sauce through a mutual acquaintance. Invited him over to the Googleplex, Figured I didn't know him, but mutual. Clayton said we should totally meet and it's like okay fine, I'll show him the rock ship, show him the ball pit, like whatever, it'll be really fun. He was a wanted to be, you know, second time entrepreneur. Knew he wanted to do something but didn't know what the idea was. I was like this, this techie but I wanted to do a startup but I didn't know what. I didn't know how to do business. So I wanted to be like, like a co pilot, somebody's pilot. And when I told him about like what I'm doing Google, but it's an extension of my open source work. So it's not like some super secret like boom based project or something like that. It's like, it's like a hybrid open googly thing. But you could do it on the outside because of Amazon. And so the big question in their conversation was like are there companies besides Google that needs something like that? It reminds me of this old quote and I forgot who said it but like the 50s or 60s, like the worldwide market for computers at 5 at the time that wasn't wrong. It was like the Cartman fence Harvard and you know what, like it was only five entities needed. So the big question when we founded it was are there only Google, Amazon, Microsoft, ebay, Yahoo. I think gaming was the acronym there. I think occasionally various acronyms can swap in and out. Or sometimes we called it like, you know, the Selenium, Google's infrastructure for the rest of us. Right. And so we found out obviously all these years later that like now, yes, there are more than five companies that use selenium testing. But it came from that once you solve the testing problem in one browser, all of a sudden you have a bigger problem. How do you maintain all these so.

Sad sauce labs that grew and then once again it seemed like you expanded your vision again where you moved to robotics. So that's where it's half the robotics. What made you get into robotics?

So I've always been into it. As a kid I had this robotic arm. And also my observation about like robotics and like pop culture, it always seems like every 10 years like there's like this robot hype wave. We're in one now. Even though I was pretty young at the time. But in the mid-80s, there was also like this panic over robotics at the time. Japanese manufacturers were coming in and that was when the robots were taking over car factories. But it spilled over in a cop culture. So you had like short circuit movie, R2D2. It was just like robots were everywhere, which means they were also in all the toy stores. I even had a little robotic arm for Radio Shack. It was my favorite besides Lego. That was my favorite. That's why. But it's been like this philosophical thing of like it's just been sitting there, it's just a toy, it does nothing. I always wanted to do something real impactful, whatever. Oddly, I know I'm gonna annoy a lot of people who might hear this, but like the, the, the selenium thing, the sauce thing, all this, that was like, that was like my, the career that I wasn't supposed to have. Like I wanted to just like make things. So along the way, like things like Maker Bear came along various different kind of open source hard work kind of projects. I was like, oh man. Like I wanna, I wanna be over there. I don't know how. It's like not exactly midlife crisis, but kind of like, ah, like I'm doing. The way I describe the cloud is like I'm flipping, you know, electrons and hard drives in a data center that I don't even know where it is. It feels very ephemeral and hard to describe to relatives that Thanksgiving dinner, things like that. But like you see a robot on a desk, it's tangible. It might not know what it does or why, but like they could say, clearly it exists and it's so I thought My interest in robotics and testing were completely divergence paths and just nothing but getting wider and wider, farther apart of my dream. So like the longer I go in software, the, the more I'm not building up experience in the revolver. I made this as part of like a little art project. I made this little linear actuator is the fancy phrase for it. But it, it's just goes, you know, forward and back.

Right.

I finally made a little prototype for it. Sometimes you can, for various robotic arms, you can use that as an actuator or when I held it upside down, I kind of realized, oh, it's actually kind of like a little button flicker. It's like, oh, that's interesting. And so I had this thought of like, I wonder if I could kind of move it, if I could add another more like again, bubblegum and duct tape kind of thing and have it click buttons on a phone at the time. On the career software side, it's like 2000. If the iPhone came out 2007, Android, I think it first released was like maybe 2008. Even though they're both working around at the same time, the big question is how mobile is different than web testing? Like, how are we going to do it? Right? And so it's kind of like a professional question of like, how are we going to do mobile testing? And it, it doesn't seem like it was really the answer, but I thought it'd be kind of funny. Like, well, I wonder if it, I wonder if part of it is like robots or something. Like. Right. Anyway, just as, as a separate thing just for the robots, I thought, I thought, like, well, I wonder if I can make it. I could make a button clicker. So this is the summer of 2011, I think angry Birds was super popular. It seems so long ago now, right? So like, okay, that's, that's my design goal. We're gonna make a little button clicker thing, play Angry Birds and whatever. I put that together. I thought it was just gonna be art project, just kind of get like the robot y part of me, like I wanted to like, just. It's kind of like a hobby. I was getting frustrated that I wasn't doing anything with it. So I was going to just start making stuff. I got a membership tech shop, San Francisco. Even though I live in Chicago, I was here so much that I got a tech shop membership here. And so when at every available moment I would go and hang out in laser cutters, make stuff. But I made this thing. What happened was I showed it off this conference and people came up to me and they skipped the whole Angry Birds video game playing part of it. And they just. And something weird happened. They were like, hey, I work in like, the secret robot lab at company xyz and we use robots to click buttons all day long. I'm like, oh, really? I didn't know that. And they're like, hey, we should totally talk. I'm like, oh, okay. So I started making fits and kind of selling them, but like, almost at cost, the first orders. It was odd because I would have to wait three weeks until the next time I came to San Francisco to get the tech shop laser cutter to make more parts to. But I started having really weird conversations with lots of companies that we all know, but they all have secret robot labs. Big difference between the hardware world and the software world is that, like, they're very secret. Keyword, secret. So that's. So that was if. That was five years ago. It was kind of a hobby for a while. And then I got a large order for these robots from a very large car company that. And at that point it was like, whoa, this isn't a hobby anymore. Like, I like, they're taking it seriously. I should take it seriously. So that a couple months later, I formally incorporated TAPS for robotics. If nothing else, I was just imagining this doomsday scenario where they're like, something bad happens. And then they're like, well, how'd you guys test it? Like, oh, yeah, we did. We did everything. Like, talk to that guy, right? That's it. Yeah, we use the robots. You know, it's his fault. Right. So I definitely wanted to have a company to make sure that, like, I'm protected. And anyway, so it's been kind of on this journey. So.

So what's a use case for the. The robotic sound that you have? I mean, yeah, I know it's a lab, but start off driving a mobile app using Angry Birds. I mean, other. After a lot of user cases that.

So when I first did it, I felt like I had a hunch and it was. I had these conversations, but it's like, okay, is there a real thing here? I've learned that there's now actually a bunch of verticals. There's obviously device manufacturers. So all the usual suspects for like, if you. Whatever devices, you know, in your pocket or sitting on your desk, the people who make those things have the secret Roku by labs. The other one is all the car companies. So if everything. Thanks to Tesla, but everything is Permian touchscreen. That's. It's kind of like the touchscreenification of the world. Everything that were like physical dials are all now touchscreens. And then that means all the companies that were otherwise making mechanical switches are now having software companies or have to hire companies that are now software companies as opposed to making a mechanical switch. So a lot of companies in a lot of different industries are freaking out because they're deficient on software development, including testing practices and all this stuff like that. So anyway, so device manufacturers with the touchscreen, basically car companies. And then also there really is something to this whole Iot thing. Like for a while it's been recounted this one buzzard. So what the particular use case in this is like you've got an iPhone and you got some kind of Bluetooth device. And then the scenario is like, what happens when. And they do something together and it's really important, right? The iPhone connects, it's your toaster, it's refrigerator, it's whatever. And there's scenarios like what if the Bluetooth disconnects or what if WI fi disconnect or something. Or what if a phone call comes in and interrupts something that was really important like a streaming video or something like that. And so sometimes you actually have to fit. You have to hit buttons on the phone, sometimes you have to hit physical buttons on the device. But either way, it's a very real world, real world scenario, right? Kind of like mapping it to kind of like the cloud. It's like it could, you could run that in the cloud if you had an entire warehouse, almost like a Noah's ark kind of a thing. Or you had a bunch of one device of everything and one of every, like, you know, Bluetooth light bulb and a car, it gets kind of ridiculous. So there's this thing where when you have devices talking to other devices, I mean, there's no real like jump to a network that scenario. Sometimes the only way to test is like to literally kick the thing. Also there's some scenarios where so it just kind of. It was like a real world test. Like they had one scenario where they had the requirement that they couldn't modify the phone in any way. It had to be completely like an untouched off the shelf thing. Their scenario is they wanted two phones talking to each other. In this case, they were interested in the server responses, but they needed to trigger the text messaging back and forth to each other. So they're using the robot to update their Facebook chats. My first version, if you remember this old startup called yo, it was a flash in the pan. They might Be silhouettes. But it was great. It was like a one word text messaging thing where you could just send your. And so my first demo was like just two robots yoing each other back and forth. I was pretty impressed with some. I upgraded the demo to playing. It was a duet of GarageBand. Similar to what Jonathan Lips is doing. Yeah.

But with the taps for robot of playing Heart and soul. Right? Yeah, yeah, that. Anyway, so when I first started it I thought it was just a fun kind of hobby art projecty thing. And now I realized like real companies need this stuff. It's kind of like a total world class resort though. Like if, if you could run it in a simulator, do that. If you could run it through the API through USB cable. Sometimes you just. There's no other option.

So that brings up a good point. I'm always wondering. I've been Test automation for 17 years now and doing UI automation. I had better luck with performance tests because it was headless and it was like HTTP communication. Where do you see the future? I mean I, I just see at some point UI automation is just not feasible. It's not like for the large projects there's got to be a better way.

Right. At some point you basically design something that is, acts like a human in every, every way. So at that point you basically have something like the Terminator where it, it can test and it can do any interaction human good to the point where it's so good that you don't know it's a robot. So those are the two things. You basically have the Matrix or Terminator as far as where functional testing will go. Right, right. Uh, and then as far as the. What do the humans do? I think at some point you're not exactly writing tests. Like right. Lines of code you might be modifying like AI algorithms that spit out test sweetness. And so you're kind of like setting like the initial conditions to spit out like all the various scenarios that you want. So you're kind of like stepping one step ahead. The other one is potentially like you're throwing a lot of spaghetti at the wall. Like you're doing a bunch of stuff, it's kind of random. And then. Excuse me, the, the tester is more almost like a data analyst where you're looking at a lot of dashboards, kind of like, like if you'd be looking at like a Google Analytics dashboard, you're just looking at instead of like people, traffic, you're looking at like maybe robots or AI. We're just exploring your app. And now you're trying to find the aggregate data of where they're going, where they're not going. So it becomes very much like a data analyst kind of a thing. So maybe you're not. You're not actually clicking the buttons. Robots are doing that for you, but you are analyzing their behavior. Sometimes you are intending them to do stuff. Sometimes it's random. No. Anyway, so I. I could see it, like, testing will never go away. Right? But maybe the days of someone, like, looking up the Selenium API and say, like, how do I, you know, get that window to go away? Like, how do I actually make that a double click and not a single click? Maybe that'll be.

You won't spend as much time doing that. Right, right, right. That's the cool.

All right, so how soon do you see that happening?

I don't know. So I. I read.

So, like, so we really are in this middle of this, like, you know, existential crisis, you know, robot. Yeah, whatever. What do you want to call it? I read all the articles.

But there are some people that are doubting, like, okay, fine, if the robots are going to equal jobs, like, okay, where are they? I don't see them. Right. Sometimes robots are like a metaphor for, like, the software. It's not the physical robots. Right. But either way, it's like, I think everyone's expecting it and super nervous. That's going to happen today, tomorrow.

But it'll probably happen, but way later. Like, it's going to be complicated. I remember in the late 90s, people were talking about, like, set top. The big. The big Dex thing was like interactive TV, right?

Y.

And that was like the late 90s. And then. And then it didn't happen. But then it totally happened. Now you can watch TV on your phone and you can click buttons. All the things that they promised in the late 90s for interactive TV totally happens now 15 years later. But they all thought it was going to happen in the next, like, three or four years. So we're probably off by like 10 or 15 years. So it's going to happen, but we've got some time. I think we've got 15 years to figure out, like, to find our next job. I don't think it's happening next year anyway.

Awesome.

But the one thing, though, one of my other hobbies is looking up how the job descriptions for various testing jobs.

Okay. Yeah.

And so I was looking up at Tesla and. And so manual testing. I mean, this is a big debate, right? Manual testing versus automated testing. Like, what do you do as manual tester? There's a totally awesome manual testing job at Tesla. And it's basically like you get to drive around a track at 90 miles per hour all day long. Like that's your job is you drive, you drive Tesla cars. That's manual testing. That's a manual testing. Manual testing job. Why aren't they coming to sleeping Crimes? Like.

Or, or whatever. But. So I think the job is absolutely changing. But you're not going to be sitting at a keyboard video mouse clicking button. It's going to be, you're going to be doing like, you might have to like hike up to Half Dome because you're testing, you know, some GPS connections, you know, because all the, I'm just imagining some weird scenario where you really have to get out in the world and test something. And if right you're, you have your Terminator, but the battery pack doesn't last to get all the way to the half dose. At some point you're gonna have to send an expedition to test all the equipment.

Right.

Like that's gonna, like, it'll always be there. But the jobs are gonna severely change. It's not gonna be, you know, a cup of coffee in the corner, go to the office, write a bunch of tet checking your spreadsheet. Like I think those days are kind of a. Right, right.

But hey, thank you Jason, once again for your automation awesomeness. Links of everything of value we covered in this episode. Head on over to.

And if you haven't already, make sure to click on the link to join the community for even more day to day 247 automation awesomeness. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is help you succeed in creating end to end full stack automation awesomeness. As always, test everything and keep the good.

Cheers.

Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges. We're excited to collaborate. Visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

Oh, the Test Guild Automation Testing Podcast with lutes and lyres the bards began their song. A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.