Now that I have your attention, let me tell you why Selenium is bad. People throw the kitchen sink at their test suites and then never fully understand why their tests are
● Slow
● Brittle
● Take an age to run (Who has a test suite that takes a day to run?)
And this is likely just on one browser. If we add another browser? The complexity grows exponentially!!
The truth is, yes Selenium can be slow, it can be brittle, it make you do some of the set up yourself. However, Is the reality that Selenium is the problem in our lives?
The problem with browser automation is that it is overused. People don’t understand how the asynchronous nature of browsers really work. And let’s be honest, browsers are hard, they’re operating system level hard.
But for now, let’s blame Selenium for our woes. I mean, it is the most common denominator.
The reality is... Poor test architecture, poor setup and the general “selenium isn’t coding so why practise good development hygiene” are ruining your lives. Implicit knowledge is codified and then people forget that it exists
In this talk, I will talk about the things that I have learned in supporting BrowserStack customers, the common mistakes to make sure that you don’t have to. I will also talk about how Selenium is gives complete flexibility for you to choose -
● Test assertion library
● Test analytics or logging tool
● Test runner

 ● Test platform - Standalone or grid setup or headless And it has awesome features like
● Support all desktop and mobile platforms
● Scales better with solid community support
Note: We are a framework-agnostic organization. We have customers that use BrowserStack at scale with many frameworks including Nightwatch, WebdriverIO, Playwright, Puppeteer, Cypress and of course, Selenium. This talk is a result of my personal frustrations on why Selenium is hated on so much when the fault clearly aren’t Selenium’s.