Meet JASON HUGGINS, The Genius Behind Selenium!

[00:00:34] Joe Colantonio Hey, welcome to another episode of the Test Guild Automation Podcast. This week, in honor of SeleniumConf 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 Selenum himself, Jason Huggins, recorded live at SelenimConf 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. Now, you could finally hear Jason and all his audio file glory as he shares the origin story of selenium and even dives into the early rise of automation in robots. You don't want to miss it. Check it out.

[00:01:30] Joe Colantonio Can you just tell us why you created Selenium, what was your thought, and did you ever think it could get as big as it actually got?

[00:01:35] Jason Huggins Right, I mean, so it's how much can do you have it, right? So I have no short stories. I was the tech lead on this project and Jim Evans at the SOSCon this week gave a couple of a version of it. It's mostly correct. But we came down to I was a tech lead on a project that so we had 10 or so people working. We're working on an internal time expense tool. And the mandate for this was it 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 extending in England and India and whatever. So all of a sudden, the latency, that was fine. That local area network in Chicago also was a huge problem when people from London were connecting to the Chicago system. The current system was like super slow. Have it fast, fast, fast. That sets the context for why for details I did later. This is actually 2003, 2004, still actually kind of in like the .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. That's kind of, that sets the scene. So, hey, it's 2003, 2014. Let's do this web thing. It's been around for a while. 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 fast-forwarding to Selenium. We wanted to, in a timesheet or a billing kind of context, we want to have this little web form. And we want it to have, if you had more than 10 items in your expense report, or whatever, you want to add a row. The state of the art in a web app would be to send that whole thing to the server. The 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. I had this idea like wait a second actually if you go into this is JavaScript thing like you can modify the web page and like add you can change the page whoever you want and you can avoid a trip to the server, it's awesome. The downside is that the time java JavaScript was super flaky and inconsistent between all the different browsers. We had very strong discussions amongst the engineers where it's like you shouldn't use JavaScript. Using JavaScript as career limiting move. It is a bad idea and you're a bad person. You should feel bad using JavaScript. This is like 2003, 2004. That's 2004. Actually, I let them win the argument for a month, we re architect it. Everything went to the server and came back and then it of course it was slow. It's like no, screw it. So put in the code to add this like to dynamically add a row to your expense report, but then as it proved out to be. We had, I called it like the sine wave equality where it would happen 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 it's like Firefox .9 Mozilla was a browser. They would be working and Firefox, but they would accidentally break an IE. Of course, they didn't test it in IE because their personal browser is 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 can't get them to test all the browsers all the time every time they touch something. I want a test two browsers. It was also knowing that just things were breaking that were working yesterday. I wanted something as kind of like a regression kind of a check before they push implement this one rule of like there has to be at least one functional test for whatever you do before you put in production. Anyway, so I wanted to have a test 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 mechanizes 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 because microsoft had like 95% market share, why would you test any other browser? I had other conversations about that. Why would you care about two browser? That's pointless. It's just a bunch of hippies care about the other stuff. Oh, and that Apple thing. Oh, yeah. Apple's dead. I mean, again, this is the world.

[00:06:05] Joe Colantonio People don't realize that.

[00:06:06] Jason Huggins But that would allow for a JavaScript limiting move, Apple. Yeah, that's kind of, that's cute. But like he does do video processing. We don't do, whatever. But we were like a trendsetting consulting company. Everyone had MacBooks and three jobs were and everyone was using is all. Whatever. I didn't want to create a testing tool. Again, long story. Sorry. We sought out other open source tools. The closest was the JS units. 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, it was a Java project and kind of it was like a headless browser, had a kind of a JavaScript thing, but it wasn't a real browser. You couldn't tell if that matched a real browser experience. Again, like the requirement was two browsers, like one test, 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. There was really nothing. I actually took a break from the project I was leading kind of to start a side project, we kind of found a conference room and just like disappeared for a month is me and like two other thought workers, Paul Gross and then Gina, sorry, Tina, she goes with Tina Wang. There's a three of us working on a month for like a month on this first thing. And then we had it and the people came by. Actually thought we were going to be famous for this time to expense app that we were making as it was super, super cool. There was a whole other story where we like evaluated all the time and expense sit things that were out there. Of course, like, big surprise for your 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 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 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 monitors, see it go. 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 it would be running on the computers in my office and I would forget that it's at the top of the hour. It's kinda 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 time of the hour and sometimes I forget it's kind of like Big Ben, blasting all of a sudden. I hear this clicking from the computer. The monitor would be off but IE sends when you click, too long of a story. But people would come in and ask me about our testing tool. I wanted to talk and pivot to Time to Expense app. Right. It was super, super cool. This is just one part of it. I think, here's your other question. I think I realized it was like a thing 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, where another people in London and whatever we're telling their clients about it. That's actually one of the things that we've made it easier. It was easier to open source it, to get it to our clients. Some of them had really weird procurement policies. It's easier just to open-source it, download it as opposed to negotiate some kind of agreement. 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.

[00:09:38] Joe Colantonio That's awesome.

[00:09:38] Jason Huggins It came from a very technical thing. I didn't want to test straight, created testing tool, but it like fell into it. I didn' know at the time there was a testing industry. There were books. There was like you could have an entire career. And it was just like this annoying problem where JavaScript was like bumming me out.

[00:09:52] Joe Colantonio Yeah, so you had a problem, you scratch your own itch and all of a sudden, a lot of people really benefited from it.

[00:09:58] Jason Huggins Sorry, it's super luxury.

[00:09:59] Joe Colantonio No, it's cool. 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 the test it, and then all of the sudden you get into cloud. Once again, early 2008, I think it's really early was it 2008 for our software?

[00:10:14] Jason Huggins Yes, found it. Selenium was the very first release of Selenium. Was like first beta or what do you want to call? First prototype. It's like April 2004. It was actually, I think, formerly released as a project in like fall 2004. And we founded SauceLabs in July of 2008. And before that, I left ThoughtWorks to go to Google. And so I've been accused of planting the seeds of a problem in whatever I create. It solves a problem, it creates a problem. And so the next problem, now that you can test in every browser, the problem is running a lab of all these browsers. If you have 100 machines, half of them are arbitrary. Half of them were IE, half were Firefox. What if Safari comes out or Chrome comes out. Would you buy more machines or you split up your lab? That's the job. There were precursors to that. I think I noticed. So it was a project when I still had ThoughtWorks. The developers were threatening mutiny because the build was taking 20 minutes. I mean, it's a pretty simple leap of like, okay, these guys are about to not care about testing at all. But it comes down to like, it was 20 minutes, like, well, how many tests do we have? It's running on one machine. 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 were like, this is awesome. Like, wow, that's weird. I wonder if that is unique to just this group of people. It probably isn't, right. I think right around that time, a lot of people were realizing, like, oh, yeah, having lots of Selenium tests. If you run 100 sequentially on one machine, it kind of bums you out. A lot people started dabbling with making a grid. But before the word cloud was a thing. There's various conferences, but one of them was KitCon is the name of the 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, but they called it grid computing, and you could rent their machines, or whatever, in the network, whatever. They didn't call it that, but for like a dollar a minute. But the thing was, when I was looking like, oh man, how do I just get quick disposable access to a bunch of machines in 2006 or 2005? I remember at that KitCon conference, I think there's grid computing thing, I think it's totally a thing. I think that's a little too expensive. The dollar a 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 Elastic Cloud and it's ten cents a minute instead of a dollar. And then all of a sudden. 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. That's even better. But at that time, I was 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? It's one of those things of like, so true about all inventions, they're almost always invented simultaneously on two different corners of the planet. It just comes down to a race to whoever 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 Selenium farm. This became this and it started with the rightly team. It's just like now Google Doc. It became this virtual cycle where the more people internally at Google heard about this. Wow, they went through an hour long to couple minutes. The more teams wanted to be part of Selenium Farm, which means then we had more budget to add more machines. It became this huge thing where we kept on adding machines, adding more clients. That was that Google. But the problem is like, well, who besides Google could just have thousands of machines or whatever, except for Amazon's EC2 and skipping ahead. I met my co founder at SOS through mutual acquaintance, invited him over to the Googleplex figure. I didn't know him, but mutual acquaintance said we should totally be here. And it's like, okay, fine, I'll show the rock, I'll show the ball pick, like, whatever, it'll be really fun. He wanted to be a second time entrepreneur. Knew he wanted to do something, but didn't know what the idea was. I was like this techie, but I wanted to start it, but I didn't know how to do business. I wanted it to be like a co-pilot somebody's pilot. And when I told him about what I'm doing at Google, but it's an extension of my own source work, so it's not like some super secret moon base project or something like that. It's like a hybrid open 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 that secret 50s or 60s like a worldwide market for computers that five at the time that wasn't wrong it was like department fans Harvard. It was only five entities needed so the big question when we founded it was is 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. Sometimes we called it like, the Selenium, or Google's infrastructure for the rest of us, right. And so we found out obviously, at least years later that like, now, yes, there are more than five companies, eight Selenium testing, but it came from that once you solve the testing problem, the one browser, all of a sudden, you have a bigger problem, how do you maintain all these pressures.

[00:15:19] Joe Colantonio SauceLabs, and then once again, it seemed like you're expanding your vision again where you moved to robotics. That's where it taps to robotics community. What made you get into robotics?

[00:15:30] Jason Huggins I've always been into it as a kid. I had this robotic arm. And also, my observation about robotics and pop culture, it always seems like every 10 years, there's 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 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 pop culture. So you had short circuit. The movie, R2-D2, it was just like robots forever, which means they were also in all the toy stores. I even had a little robotic arm from Radio Shack. It was my favorite. Besides Lego, that was my favorite. But it's been like this philosophical thing of like, it's just been sitting there, it's a toy, it does nothing. I always wanted to do something real and practical. Oddly, I know I'm gonna annoy a lot of people who might hear this, but like the Selenium thing, the SOS thing, that was like my career that I wasn't supposed to have. I wanted to just like make things so long the way like things like ..... came along various different kind of focus or hardware kind of projects. I was like, oh man, like I want to 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 described the cloud is like I'm flipping 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 of Thanksgiving dinner things like that. But like, you see a robot on a desk, it's not tangible, it might not know what it does or why, but like they could say clearly it exists in this thing. I thought my interest in robotics and testing were completely divergence paths and just nothing but getting wider and wider, farther apart of my dreams. So like the longer I go in software, the more I'm not building up experience in robotic. I made this as part of like a little art project, I made little linear actuator, is the fancy phrase for it, but it just goes forward and back. And I finally made a little prototype for it. Sometimes you can, for various robotic arms, you can use that as an actuator. Well, 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. I had this thought of like, I wonder if I could kind of move it, if I can add another more like, again, bubble gum and duct tape kind of thing, and add 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 the first release was like in 2008, even though they're both working around at the same time. The big question is how mobile is different than web testing. How are we going to do it. It's kind of like a professional question of, how are we gonna do mobile testing? And it doesn't seem like it was really the answer, but I thought it'd be kind of funny. Well, I wonder if part of it is robots or something, right. Anyway, just as a separate thing just for the robots, I thought, well, I wondered if I could make a button clicker. This is the summer of 2011, I think. Angry Birds was super popular. It seems so long ago now, right, okay, that's my design goal. We make old button clicker thing, playing your birds and whatever. I put that together. I thought it was going to be art project. Just kind of get like the roboty 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. I was going here to start making stuff. I got a membership tech shop, San Francisco, even though I live in Chicago. I was here so much that I thought a tech shop membership here. And so when at every available moment, I would go and hang out and laser headers, 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 something weird happened. They were like, hey, I work in 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, we should totally talk. I'm, like, OK. So I started making fits and kind of selling them, but 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 to TechShop or LaserCutter to make more parts. 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 they're very secret, keyword secret. That was 5 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 and at that point It was like, whoa, this isn't a hobby anymore. They're taking it seriously. I should take it seriously, so that, a couple of months later, I formally incorporated Tapster Robotics. If nothing else, I was just imagining this new state 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 everything. Talk to that guy, right? We used the robots. It's his fault, right. I definitely wanted to have a company to make sure that I'm protected and anyway, so it's been kind of on this journey since then.

[00:20:13] Joe Colantonio It's a use case for the robotic sound that you have. I mean, yeah, I know it's a lot of it's sort of, but start off driving a mobile app using Angry Birds. I mean now they're after a lot of user cases that.

[00:20:23] Jason Huggins When I first did it, I felt like I had a hunch.

[00:20:25] Joe Colantonio And it was, I had these conversations, but it's like, OK, is there a real thing here. I've learned that there's now actually a bunch of verticals. There's obviously device manufacturers. All the usual suspects for like if you whatever devices, in your pocket or sitting on your desk, the people who make those things have the secret overlap. The other one is all the car companies. If everything affects Tesla, but everything is coming a touch. It's kind of like the touch screenification of the world. Everything that were like physical dials are all now touch screens. And that means all the companies that were otherwise making mechanical switches are now having to become a software company or have to hire companies that are now software companies as opposed to making a mechanical switch. A lot of companies and a lot of different industries are freaking out because they're deficient on software development, including testing practices and all that stuff. Device manufacturers with the touchscreen, basically, car companies. And then also, there really is something to this whole IoT thing. Like, for a while, I still remember having this one-.

[00:21:23] Joe Colantonio Sweet. Buzzword.

[00:21:25] Jason Huggins What the particular use case in this is that you've got an iPhone and you've 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 to your toaster, it's your food right here. It's your car or whatever. And there are 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 since sometimes you actually have to fit, you have to hit buttons on the phone, sometimes you have hit physical buttons on the device. But either way, it's a very real world scenario. Kind of like mapping it to kind of like a cloud, it's like 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 Bluetooth light bulb in a car. It gets kind of ridiculous. There's this thing where when you have devices, talking to other devices, so there's no real jump to a network, that scenario sometimes the only way to really test is to literally kick the thing. Also, there's some scenarios where it was like a real-world test. They have 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. There are scenarios 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 another. 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 slower, but it was great. There's like a one word text messaging thing where you can just send your friend Yo. And so my first demo was like just two robots going to each other back or forth. I was pretty impressed with some. I upgraded the demo to playing. It was a duet of Garageband. We're not what John is the lips is doing. But with the Tapster for a lot of playing heart and soul that anyway. When I first started it, I was just a fun kind of hobby or project you thing. And now I realized like real companies need this stuff. It's kind of like a total class resort though, like if you could run it in a simulator to that if you run it through the API, through USB cable, sometimes there's no other option.

[00:23:33] Joe Colantonio That brings up a good point. I'm always wondering, I've been test automation for 17 years now. And during UI automation, I had better luck with performance tests because of its headless and it was like HTTP communication. Where do you see the future? I mean, I just see at some point, UI automation is just not feasible. It's not like for the large projects, there's gotta be a better way.

[00:23:56] Jason Huggins Some point you basically design something that is acts like a human in every way. At that point, you basically have something like the Terminator where it can test and you can do any interaction with human goods to the point where it's so good that you don't know it's a robot. Those are the two things you basically the matrix or Terminator as far as where functional testing will go. And then as far is it what the humans do, I think at some point you're not exactly writing tests like lines of code. You might be modifying like AI algorithms that spit out test suites and so you're kind of like setting like the initial conditions to spit out like all the various scenarios that you want. You kind of like what stepping one step ahead. The other one is potentially like throwing a lot of spaghetti on the wall like you're doing a bunch of stuff it's kind of random. The tester is more almost like a data analyst where you're looking at a lot of dashboards. Kind of like if you'd be looking at like a Google Analytics dashboard. Where you're just looking at, instead of like people traffic, you're look 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 are not going. It becomes very much like a data analyst kind of a thing. Maybe you're not actually clicking the buttons, robots are doing that for you, but you're analyzing their behavior. Sometimes you're intending them to do stuff. Sometimes it's random. Anyway, I could see it like testing will never go away but maybe the days of someone like looking up the Selenium API and say like how do I get that window to go away. Like how do we actually make that a double click and not a single click. Maybe that'll be, you won't spend as much time doing that.

[00:25:38] Joe Colantonio How soon do you see that happening?

[00:25:42] Jason Huggins I read, we really are in this middle of this existential crisis robot, whatever. What do you want to call it? I read all the articles. But there are some people that are doubting, like, OK, fine. If the robots are going to go to jobs, like. OK, where are they? I don't see them, right? Sometimes robots are like a metaphor for lectures the software is on the physical robots. But either way, it's like, I think everyone's expecting it and super nervous that's going to happen today and tomorrow. It'll probably happen, but way later it's going to be complicated. I remember in the late 90s, people were talking to like set up the big next thing was like interactive TV. And that was like the late 90s. 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 90's for interactive TV totally happens now, 15 years later. But they all thought it was going to happen in the next 3 or 4 years. So we're probably off by like 10 or 15 years. So it's gonna happen. Well, we've got some time, I think we've got 15 years to figure out how to find our next job. I don't think it's happening next year, anyway. But the one thing, though, one of my other hobbies is looking up how the job descriptions for various testing jobs.

[00:27:02] Joe Colantonio OK, yeah.

[00:27:04] Jason Huggins And so I was looking up at Tesla. And so manual testing, I mean, this is a big debate, right, manual testing versus automated testing, what do you do as a 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. That's your job is you drive Tesla cars. That's manual testing. That's a manual testing job. Why aren't they coming to something comes or whatever? I think the job is absolutely changing, but you're not going to be sitting at a keyboard video mouse clicking, but we're going to be doing like you might have to like hike up to Half Dome because you're testing some GPS connections. I'm just imagining some weird scenario where you really have to get out in the world and test something and if right, you have your terminator, but the battery pack doesn't last to get all the way the half dose at some point you're gonna have to set an expedition to test all the equipment. It'll always be there but the jobs are gonna severely change It's not gonna be a cup of coffee in the corner go to the office write a bunch of that, check in your spreadsheet like I think those days were kind of.

[00:28:11] Joe Colantonio Right, right. Thank you, Jason. Once again, for your automation awesomeness. The links of everything of value we covered in this episode, head on over to testguild.com/A540. And if you haven't already, make sure to click on the link to join the community for even more day to day 24/7 automation awesomeness. That's it for this episode of The Test Guild Automation Podcast. I'm Joe, my mission is to help you succeed in creating end-to-end full-stack automation awesomeness. As always, test everything and keep the good. Cheers.

[00:28:43] 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 at TestGuild.com where you become part of our elite circle driving innovation, 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.

[00:29:26] 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 testers, showing them the secrets to behold.