This spring, Sauce Labs announced the Sauce Testrunner Toolkit (beta) to expand developer-first capabilities and support for native JavaScript frameworks. The Testrunner Toolkit makes setting up, writing, and running web tests easier and faster for developers during early pipeline testing. First it supported Puppeteer, followed by Cypress, TestCafe, and Playwright to provide the flexibility to test the way you want, along with Sauce Labs insights, at scale.

Deep in the implementation of every automated UI test lives the potential to turn something simple into something slow and unreliable—simply by adding extra Selenium commands. The data clearly show that longer tests are less likely to pass. In this case study, I will show you how to optimize a test and make it 560% faster. We will do this by tackling inefficient use of Selenium commands.

As the lead of the Selenium project, I wanted to kick off a new blog series leading up to the release of Selenium 4. During this series, I’ll talk all about how the Selenium project works, who is involved, how you—yes, you!—can get involved, and we’ll get a sneak peek at what’s new in Selenium 4. I've been speaking about this off and on for a while, but now the 4.0 release is looming I wanted to start sharing in more depth.

QA professionals, testers, and developers are constantly learning new tools, tech stacks, and development practices. When they’re told they have to learn accessibility, it can often feel like an unwelcome and overwhelming disruption, slowing them down and forcing them to test and rewrite what they thought was perfectly good code. The good news is accessibility tools are more tester-friendly than ever.

Ten years ago I saw a Selenium test that could click on a capital "I" that was one pixel wide. I was not capable of clicking on it myself. Around that time, a lot of people began using phrases like "End to end is further than you think." Simulators and emulators, after all, could not simulate heat, poor memory management, low power, and other problems. Then again, that was ten years ago.

A common complaint that I hear is: “My tests run a lot faster locally than on Sauce Labs.” Sauce Labs is in the cloud and not in your local network, so it makes sense that any given test is going to have some amount of slowdown. The advantage of Sauce Labs is that you can make up this difference by scaling up the number of tests you run at the same time.

This year the Selenium Conference was held virtually, and despite that, the conference again offered an exciting place for the Selenium community to meet in order to share and learn about the most popular browser automation tool in the world. The conference offered talks about improved testing practices, new tools to simplify the setup of automated tests, the future of Selenium, and lots of learnings from speakers who shared their use cases and practical advice for how they use Selenium at work.

When your team moves to a cloud testing solution like Sauce Labs, creating a solid, secure connection is likely to be a top priority. One of the solutions to this challenge is Sauce Connect proxy. This is a command line tool that your team can use to create a TLS tunnel from your environment out to Sauce. This can be used to test applications that are not publicly facing; for example, if your team needs access to a local host system or a dev or staging environment.

Go ahead, search the interwebs. There are more posts and articles on “The Ten Commandments of Test Automation” than you can shake a test case at. Go ahead…I’ll wait. Welcome back! To set the stage, I have not read any of those articles. Well, more accurately, I’ve not read any of them recently; most of them I’ve not read at all. I probably read one or two of them in the “before times,” but I don’t remember any of the specific commandments.

Recently, we created the Sauce Labs Open Program Office to focus our attention internally on how we support and contribute to the open source community. Last week, we proudly launched a new web site with comprehensive information about the office, including best practices, contribution guidelines for the Sauce team, and a new blog where Diego Molina and Christian Bromann will write regularly about all things open source. This article is cross-posted from the new blog.