Selenium

I

I was thinking of, like, I was just thinking of, like, straight up just, like, Selenium web scrapers

or something.

Like, automating.

You are on

Selenium.

Like, the website, I'm sure, is really poor.

I feel like that stuff, the personal agent stuff, becomes quite nice.

And if you can, when you're putting an idea out there, frame it as an experiment that can easily be changed, not a life and death.

If you frame it as something like, "Let's just write, um, in, I don't know, Selenium forevermore, um, we haven't been doing that.

Well, let's move to Playwright." It's a big thing, and all the rest of it.

That's a commitment that people aren't always gonna want to buy into.

And so I feel like you brought up a bunch of different technologies and it may be good to just go over each one of them.

My understanding is Selenium is more of like a web driver.

Like you use your real browser and it's sort of like interacting with it directly.

And so I can imagine that there's a lot of complexity that goes into that interaction.

Like you're crossing processes.

Obviously, the operating system is a huge complexity there.

So like Selenium is a browser automation framework.

Let me do browser automation and do it really well.

And so I got out there and I was talking to people out in the valley and stuff.

It's like we were going into these enterprise companies doing test automation, using stuff like Selenium.

And you go around talking to people and it's like people didn't, I remember having conversations with people like Yahoo and even big chunks of Google who did not think you could do functional automated testing of like websites and stuff.

I guess because

That standardization emerged from the interplay between open source projects, browser vendors, and standards bodies like the W3C.

David Burns is a longtime Selenium and WebDriver contributor, a veteran of Mozilla, and is currently the head of developer advocacy and open source at BrowserStack.

In this episode, David joins Josh Goldberg to discuss how open source projects, browser vendors, and standards bodies fit together, a practical philosophy of testing built around one solid test per critical path, and the risks that AI and vibe coding introduce to web development.

This episode is hosted by Josh Goldberg, front end developer at Sentry and open source maintainer.

I'm really excited to be here.

Yeah, we're excited to talk with you.

You've got a lot of cool stuff to talk about, developer advocacy and Selenium and W3C and open source.

But before we get into all of that, tell us, how did you get into tech?

It's a simple intent for that application.

Now, in order for... to fulfill that intent, that application has certain capabilities, some buttons to click, some things to select, and in the end, based on that, a test case needs to be generated, which a lot of the time either was done manually or in automation, someone writing the test case that is followed to run across the automation line through frameworks like Selenium and Playwright and Appium for mobile application.

Now, that itself can be...

AI is very good at solving that.

So you talked about a few of the products that are available through Sauce Labs.

What are some other ones that if people are like, "Look, we know we've needed to do QA automation all along and we've just never done it.

We're still m- manually wiring up Selenium or Playwright now."

Yeah.

It just isn't something that was that prevalent, really.

You know, most people kind of did a bit of QA and that was kind of, you know, people at best, people had Selenium, you know, and it was kind of running in this kind of, you know, in your staging environment or whatever.

A lot of, a lot of people weren't doing test room development and Rails kind of made that really accessible to everyone and presented it in a way that's like, this is how you build software properly.

So that kind of clicked with me as well, you know, that And again, to me, like that testing side is part of being productive.

Is there a generalized frustration with the tools that exist?

Very much so, right? Like my experience in Selenium really shows that.

But a lot of the frustration is because the tool is doing something and they don't know how to interpret it.

Like for me, a really good example is for years people have said Selenium is flaky.

And then they started moving to Cypress and then Cypress started becoming flaky.

Then they started moving to Puppeteer.

And then it shoots out wide again and then goes to the top for end-to-end tests.

And that creates problems because you've got all these things where if you can limit how much you have to do to the thing that you care about to make sure that is correct, then awesome.