AI Summary
5 min readIn 2004, a team of developers at ThoughtWorks was stuck on a maddening loop. A button would work in Firefox, then break in Internet Explorer. They'd fix it for IE, push it to production, and it would break in Firefox. The next week, the same cycle. They were regressing, not progressing. Jason Huggins, then a developer on that team, built a tool to stop the backsliding. That tool became Selenium. Fifteen years later, Huggins joined the hosts of AB Testing to talk about what his creation has become—and what it was never meant to be.
The Croissant Problem
Huggins agreed with the hosts' core critique: Selenium is often used badly. But he pushed back on the framing. The hosts had argued that Selenium is a tool that enables dysfunction—separate test teams writing fragile, selector-based automation that they spend all their time maintaining. Huggins's response was a metaphor: "It sounded like you were sitting in a cafe in England complaining about the croissants and saying, 'Gosh, I can't wait to get out of England, let's get to France and we'll never have to deal with croissants anymore.'" His point was that Selenium came out of the environment the hosts were advocating for—a developer team with no separate testers, building a tool to solve a specific cross-browser regression problem. "When you're following all those principles, Selenium came out of that environment," he said. T
Continue reading the full summary in the app — free to try.
Read Full Summary →Free • No credit card required
Never miss an episode of AB Testing
Get every new episode summarized in your inbox — free, ~5 minutes to read.
No spam. Unsubscribe anytime.
What you'll learn
- 1 (00:00) **Episode Intro & Context** - Hosts set up the replay of episode 103, framing the conversation around UI automation and Selenium.
- 2 (02:39) **Jason's Reaction to Episode 102** - Jason shares his initial reaction to the hosts' previous episode on UI automation.
- 3 (04:14) **The Missing Context: Selenium's Developer Origins** - Jason explains Selenium was created by developers for developers, not for siloed test teams.
- 4 (08:39) **The Core Agreement: Siloed Teams Are the Problem** - The hosts and Jason agree that separate test and dev teams are the root cause of bad UI automation.
- 5 (10:17) **Selenium's Developer Roots vs. Marketing Myths** - Jason pushes back on the narrative that Selenium isn't a "real developer tool."
- 6 (12:04) **The Two Paths for Testers** - Jason describes the two directions testers are being pushed: toward coding automation or toward analysis.
- 7 (13:09) **Dev Ownership vs. Test Ownership** - The hosts cite Nicole Forsgren's *Accelerate* research showing dev-owned testing correlates with positive business outcomes, while test-owned testing does not.
+ Full timestamped outline available in the app
Show Notes
In this replay of episode 103, we are joined by Jason Huggins, the creator of Selenium, to discuss the true intent of the tool and why the industry has developed what Alan calls a 'tragic sickness' and an 'unhealthy infatuation' with UI automation. Driven by his belief that hand-crafted UI tests are an inefficient 'money pit' and a 'maintenance nightmare,' Alan challenges the traditional reliance on Selenium and advocates for developers owning automation to ensure better code design. Together with Huggins, we explore the history of the 'mercury monster' and the 'Steel Cage Match' while looking toward a future where robotics, AI-assisted record-and-playback, and data-driven experimentation replace brittle, legacy scripts
More from this podcast
AB Testing →