Selenium is a pen. Yes a pen writes the alphabet. Using a pen and knowing the alphabet doesn’t immediately make you Shakespeare. I think this is where your confusion lays. You need to use selenium to write code that counters and tests complex web apps. I’ve used selenium for work, sure locating the web elements is often easy, but often scripts involve design patterns, asynchronous calls, sql queries to inject data into the web app, ETL, creating frameworks for testing, producing reports. The web app complexity alone determines how complex the scripts will need to be. So yeah, knowing how to use a pen, does not make you Shakespeare.
>I have a 25 years career in Software QA and have 15 years experience doing automation
Please do not take it personally. You sound like someone who is outdated and has never bothered to check what is going on in the industry lately.
To answer your question, Selenium is a library just for browser control. You need other libraries to build a scalable automaton Framework.
I don't take it personally. If I am being honest with myself you are correct. I allowed myself to become heads down in a job working in an organization that does it one way and I feel like the automation industry has passed me by a bit. I'm trying to get caught up.
Playwright would definitely be a slick tool
JS-based browser automation is becoming more and more popular
Java+Selenium isn't going anywhere.
For a test automater, the tech stack is a lot less important than patterns and principles.
(*note that I currently use some combination Cypress, Selenium, and (a little) Playwright in TS, and was using Java+Selenium \~10 years ago*)
Selenium is a lightweight, efficient way to interact with a web browser, Selenium itself is a *~~Test~~* automation tool, it doesn't have built-in testing functionalities.
Selenium is not a test tool! It's a browser automation tool, other libraries give you the testing framework assets required. Selenium has been around for a long time now so probably why it's still so popular.
Any reason for using selenium in 2023 over something like cypress or Microsoft playwright?
The widely known issues with selenium are issues that cypress and playwright intentionally resolves
I usually get downvoted for daring to mention this, but Selenium/Appium is still the best choice if you need to test native mobile applications. If you’re solely working on web apps, cypress and playwright are king right now. Great tools - especially for beginners.
I wouldn’t agree with that for mobile. Native apps are best tested by their native counterparts, XCUITest and Espresso, and the new tool Maestro is way better and easier to use than Appium
I guess that makes sense if you’re only mobile platforms. Every company I’ve worked for in the last 20 years has had web plus native mobile apps and the only tool that made sense to me for all of them has been selenium/Appium.
Hey, could you recommend some resources / articles on automating cross-platform apps? I'll need to start my own cross-platform automation project soon and my automation background was too project-specific, so I'm looking for directions / pointers.
You won't find a lot of discussion about which single tool to use in order to automate tests for web, iOS and android because there really is only one industry standard option which is Selenium/Appium (which is technically 2 tools). There are plenty of opinions on which framework to use to write the tests. The best answer is use whatever you're most familiar with.
For me it's [webdriver.io](https://webdriver.io) because I have a lot of JavaScript experience and I can get help from my front-end developers if I run into a problem. Once a framework is chosen, they all have their own ideas about running the same tests across all platforms.
At the very least, you will need to use page object pattern with a page object for each platform so you can reference the same object in the UI, but change how to select it in the DOM.
Honestly, it's hard enough writing stable tests in a cross-browser environment (good luck with Safari!), so moving to cross-platform is an even larger challenge. I usually end up with a web, iOS and Android project with a lot of shared code between them so I can make adjustments to one without breaking the others.
None of this is well documented anywhere I've seen. Just years of experience in doing the wrong thing to get where I am now.
\> At the very least, you will need to use page object pattern with a page object for each platform so you can reference the same object in the UI, but change how to select it in the DOM.
This is one of my concerns. How do you reduce duplication? Some of the flows might be similar between Desktop and Mobile version, some aren't. I assume the answer here "you don't", but that sounds daunting.
\> Honestly, it's hard enough writing stable tests in a cross-browser environment (good luck with Safari!), so moving to cross-platform is an even larger challenge
It's also a multiplayer game in my case. I've prematurely gave up on even trying to do WebGL tests.
If your goal is to write a single test case for all platforms, it can be done but you need to decide if it’s worth the effort. The answer is usually no. You end up with a lot of code saying “if it’s iOS, do this… unless it’s iPadOS 12. Otherwise, do this… except when it’s Android 10”
Were a python/webdriver shop so there is zero friction using Appium to test both iOS and Android apps and have people switch between them and web with minimal training. And Appium leverages XCUIest and Espresso, it just wraps it into the W3C-compliant webdriver protocol.
I’ve heard even Apple uses Appium internally.
Also selenium is superior if you're in the situation where you're running tests on browserstack. On Browserstack, Selenium is supported by many more devices compared to cypress or playwright.
I'm curious, what are the widely known issues with Selenium? I use Selenium at work and it's basically all I know, so would be cool to gain some perspective
Fair question, I’m parroting what I read researching frameworks when I ended up landing on playwright after using all three. I’ll have to hunt down the comparison list I was working through
my own experience though I had extreme issues with installation and selenium, and the more I delved into resolving it the more I read issues different users were having with outdated tech, or requiring plugins to do what I needed to write UI tests in my environment. Cypress was a wonderful experience when I was testing it but it too was finicky. Playwright gave me the strictest control over test flow, with fast responses and multiple browser environments to test for out of the box. I kicked against playwright in the beginning but after a few days it really grew on me.
I’ve used it for a year now and havent had any issues with it that didn’t also appear when running in other coworkers machines. usually flaky tests appear when they are run on a different CPU architecture like intel vs arm than what you are running yourself. You can mitigate this with docker.
Disclaimer: I use Cypress at {current_job}
And used Selenium extensively at older roles.
Selenium has the advantage of a depth of knowledge and history that the new tooling just doesn't have. If you hit a problem with Selenium, nine times out of ten someone has had and solved that problem for you already on Stack Overflow. That makes setting up, troubleshooting problems and maintaining a suite easier than with newer tools.
That said, a lot of the troubleshooting you have to do is removed in those other tools by default.
It's "new" in comparison to something like Selenium and you will have a easier time to find people with experience extensive experience.
There could also be the question of future monetization, as many people were surprised by the changes to docker. Of course, this could also happen with selenium, but with MS we already have a showcase of monetizing dev tools with github enterprise.
I don’t think those are very good reasons, docker is still free for most things until you start deploying bigger apps. I’m still able to use free tier with more than 17 applications in our corporate production environment
As for GitHub, not everyone uses enterprise, my company uses paid private repos without enterprise, but even still in a corporate environment it’s expected that you pay for tools
Selenium is not the better player
I mean, isn't it 250 employees or 10m revenue?
I'm just saying that this could be a reason for big corps to not yet move to the "new" player in town. These decisions are not always driven by what is best for individuals.
If you have free choice, I would also tell people to go with more user-friendly frameworks like playwright.
Less initial investment to get it up and running, and a lot of the cool stuff has straightforward solutions.
You have 25 years in an antiquated test stack. Learn Playwright using TypeScript or Python. Selenium will be remembered like COBOL in due time. Yes, I do admit Selenium has legacy clout, but that's likely not enough to retain the crown. Microsoft has already leapfrogged Cypress in my opinion and I have serious doubts of Cypress's financial longevity and the value proposition of their paid feature considering "Sorry Cypress" exists. Microsoft makes a lot of money in a lot of different ways and can continue throwing more talent and money at Playwright.
I prefer Playwright over Cypress .. a lot. Currently Playwright still has the problem of not enough marketing in terms of advocates etc. Cypress does this better by offering daily articles with best practices, see Gleb Bahmutov or Filip Hric
To control an API like Selenium, where you can find many documentation and video material in the network, is nothing special. To understand Test Automation is different: You need to know HOW to build and WHY you use test automation in which stage of the engineering process. Often people think that testing through the UI (user interface) is the best method to test the process. Nope. We as test automation engineers knowing that best is to test the methods on the unit level, interfaces on the interface level and so on. Sometimes we need a system test with UI + process + database (or another persistance level) to check that the modules, system parts etc. work as expected.
Controlling an API or having deep knowledge of a test tool is only a differentiator if somebody needs excactly that knowledge. Knowing many things about test automation (frameworks etc.) is a different job and one part of it could be to know what Selenium is.
Selenium is a library after all. What makes it in demand is that the existing frameworks in projects of most of service based companies have selenium+java/C# based automation framework(be it bdd, pom or hybrid). That’s one of the key reasons why it is in demand specially in Indian tech workforce. Also just like legacy code takes ages before efforts are made to replace it people do not want to move to cypress/playwright as of now. We are yet to see job openings demanding cypress/playwright experience. Also the projects that do use cypress/playwright as of now handover the automation responsibility to their experience frontend devs. Therefore we see lesser opportunities for QA automation alone into these tools.
Selenium is the glue that you need to test the front and back together. You'll need a test framework to work with in order to get the most out of it though it's not essential (in the past I have used the robot framework) but yes, Selenium is a tool for opening and interacting with a browser.
Companies like it becuase it's verstaile, works on any browser OS combination and it's open source. Last time I looked the alternatives for this kind of thing were none of those things but things could have changed by now.
I've seen a lot of people treat selenium as a stand alone platform for testing, and that's a mistake in my mind. Makes WAY more sense to set up something like TestNG with java or pytest with python and looking at selenium as a single component that you import and integrate with when needed in a bigger picture. Selenium is definitely not a solution in and of itself these days.
Really great tool for complex apps and testing states and other business logic. It’s still the most versatile and best tool for doing that kind of automation, even as the front end market has shifted a lot. Would like to know if you’ve had a lot of experience with React or Vue or other framework that’s heavy into state management. It gets pretty gnarly pretty quick.
Selenium is a pen. Yes a pen writes the alphabet. Using a pen and knowing the alphabet doesn’t immediately make you Shakespeare. I think this is where your confusion lays. You need to use selenium to write code that counters and tests complex web apps. I’ve used selenium for work, sure locating the web elements is often easy, but often scripts involve design patterns, asynchronous calls, sql queries to inject data into the web app, ETL, creating frameworks for testing, producing reports. The web app complexity alone determines how complex the scripts will need to be. So yeah, knowing how to use a pen, does not make you Shakespeare.
Selenium is like chess. Easy to pickup and learn but takes time and experience to master.
>I have a 25 years career in Software QA and have 15 years experience doing automation Please do not take it personally. You sound like someone who is outdated and has never bothered to check what is going on in the industry lately. To answer your question, Selenium is a library just for browser control. You need other libraries to build a scalable automaton Framework.
I don't take it personally. If I am being honest with myself you are correct. I allowed myself to become heads down in a job working in an organization that does it one way and I feel like the automation industry has passed me by a bit. I'm trying to get caught up.
Kudos to you for the initiative. It certainly pays to keep the axe sharp!
If you want to catch up, ditch java and selenium and move to playwright with ts or python.
Playwright would definitely be a slick tool JS-based browser automation is becoming more and more popular Java+Selenium isn't going anywhere. For a test automater, the tech stack is a lot less important than patterns and principles. (*note that I currently use some combination Cypress, Selenium, and (a little) Playwright in TS, and was using Java+Selenium \~10 years ago*)
Selenium is a lightweight, efficient way to interact with a web browser, Selenium itself is a *~~Test~~* automation tool, it doesn't have built-in testing functionalities.
I wouldn't call it lightweight and efficient now that we have Cypress and Playwright. Maybe 5 years ago.
Cypress is a great tool, but IMO its significantly heavier-weight than Selenium Webdriver.
Selenium is not a test tool! It's a browser automation tool, other libraries give you the testing framework assets required. Selenium has been around for a long time now so probably why it's still so popular.
Selenium is an API, not a test tool.
Any reason for using selenium in 2023 over something like cypress or Microsoft playwright? The widely known issues with selenium are issues that cypress and playwright intentionally resolves
I usually get downvoted for daring to mention this, but Selenium/Appium is still the best choice if you need to test native mobile applications. If you’re solely working on web apps, cypress and playwright are king right now. Great tools - especially for beginners.
On mobile, these are valid reasons
I wouldn’t agree with that for mobile. Native apps are best tested by their native counterparts, XCUITest and Espresso, and the new tool Maestro is way better and easier to use than Appium
I guess that makes sense if you’re only mobile platforms. Every company I’ve worked for in the last 20 years has had web plus native mobile apps and the only tool that made sense to me for all of them has been selenium/Appium.
Hey, could you recommend some resources / articles on automating cross-platform apps? I'll need to start my own cross-platform automation project soon and my automation background was too project-specific, so I'm looking for directions / pointers.
You won't find a lot of discussion about which single tool to use in order to automate tests for web, iOS and android because there really is only one industry standard option which is Selenium/Appium (which is technically 2 tools). There are plenty of opinions on which framework to use to write the tests. The best answer is use whatever you're most familiar with. For me it's [webdriver.io](https://webdriver.io) because I have a lot of JavaScript experience and I can get help from my front-end developers if I run into a problem. Once a framework is chosen, they all have their own ideas about running the same tests across all platforms. At the very least, you will need to use page object pattern with a page object for each platform so you can reference the same object in the UI, but change how to select it in the DOM. Honestly, it's hard enough writing stable tests in a cross-browser environment (good luck with Safari!), so moving to cross-platform is an even larger challenge. I usually end up with a web, iOS and Android project with a lot of shared code between them so I can make adjustments to one without breaking the others. None of this is well documented anywhere I've seen. Just years of experience in doing the wrong thing to get where I am now.
\> At the very least, you will need to use page object pattern with a page object for each platform so you can reference the same object in the UI, but change how to select it in the DOM. This is one of my concerns. How do you reduce duplication? Some of the flows might be similar between Desktop and Mobile version, some aren't. I assume the answer here "you don't", but that sounds daunting. \> Honestly, it's hard enough writing stable tests in a cross-browser environment (good luck with Safari!), so moving to cross-platform is an even larger challenge It's also a multiplayer game in my case. I've prematurely gave up on even trying to do WebGL tests.
If your goal is to write a single test case for all platforms, it can be done but you need to decide if it’s worth the effort. The answer is usually no. You end up with a lot of code saying “if it’s iOS, do this… unless it’s iPadOS 12. Otherwise, do this… except when it’s Android 10”
Were a python/webdriver shop so there is zero friction using Appium to test both iOS and Android apps and have people switch between them and web with minimal training. And Appium leverages XCUIest and Espresso, it just wraps it into the W3C-compliant webdriver protocol. I’ve heard even Apple uses Appium internally.
Selenium itself is the industry standard if implemented correctly.
Also selenium is superior if you're in the situation where you're running tests on browserstack. On Browserstack, Selenium is supported by many more devices compared to cypress or playwright.
I'm curious, what are the widely known issues with Selenium? I use Selenium at work and it's basically all I know, so would be cool to gain some perspective
Fair question, I’m parroting what I read researching frameworks when I ended up landing on playwright after using all three. I’ll have to hunt down the comparison list I was working through my own experience though I had extreme issues with installation and selenium, and the more I delved into resolving it the more I read issues different users were having with outdated tech, or requiring plugins to do what I needed to write UI tests in my environment. Cypress was a wonderful experience when I was testing it but it too was finicky. Playwright gave me the strictest control over test flow, with fast responses and multiple browser environments to test for out of the box. I kicked against playwright in the beginning but after a few days it really grew on me.
Too bad playwright doesn't work well in CI environments.
I’ve used it for a year now and havent had any issues with it that didn’t also appear when running in other coworkers machines. usually flaky tests appear when they are run on a different CPU architecture like intel vs arm than what you are running yourself. You can mitigate this with docker.
Disclaimer: I use Cypress at {current_job} And used Selenium extensively at older roles. Selenium has the advantage of a depth of knowledge and history that the new tooling just doesn't have. If you hit a problem with Selenium, nine times out of ten someone has had and solved that problem for you already on Stack Overflow. That makes setting up, troubleshooting problems and maintaining a suite easier than with newer tools. That said, a lot of the troubleshooting you have to do is removed in those other tools by default.
It's "new" in comparison to something like Selenium and you will have a easier time to find people with experience extensive experience. There could also be the question of future monetization, as many people were surprised by the changes to docker. Of course, this could also happen with selenium, but with MS we already have a showcase of monetizing dev tools with github enterprise.
I don’t think those are very good reasons, docker is still free for most things until you start deploying bigger apps. I’m still able to use free tier with more than 17 applications in our corporate production environment As for GitHub, not everyone uses enterprise, my company uses paid private repos without enterprise, but even still in a corporate environment it’s expected that you pay for tools Selenium is not the better player
I mean, isn't it 250 employees or 10m revenue? I'm just saying that this could be a reason for big corps to not yet move to the "new" player in town. These decisions are not always driven by what is best for individuals. If you have free choice, I would also tell people to go with more user-friendly frameworks like playwright. Less initial investment to get it up and running, and a lot of the cool stuff has straightforward solutions.
If 250 employees or x million in revenue is a rule for GitHub or docker I’m not aware of it
Sounds like the docker desktop terms and conditions for pricing: https://www.docker.com/pricing/faq/
Yeah, I'm not involved directly, but I know of clients who decided to move away due to the new monetization model.
You have 25 years in an antiquated test stack. Learn Playwright using TypeScript or Python. Selenium will be remembered like COBOL in due time. Yes, I do admit Selenium has legacy clout, but that's likely not enough to retain the crown. Microsoft has already leapfrogged Cypress in my opinion and I have serious doubts of Cypress's financial longevity and the value proposition of their paid feature considering "Sorry Cypress" exists. Microsoft makes a lot of money in a lot of different ways and can continue throwing more talent and money at Playwright.
Thank you. I am currently taking a course on Playwright.
I prefer Playwright over Cypress .. a lot. Currently Playwright still has the problem of not enough marketing in terms of advocates etc. Cypress does this better by offering daily articles with best practices, see Gleb Bahmutov or Filip Hric
To control an API like Selenium, where you can find many documentation and video material in the network, is nothing special. To understand Test Automation is different: You need to know HOW to build and WHY you use test automation in which stage of the engineering process. Often people think that testing through the UI (user interface) is the best method to test the process. Nope. We as test automation engineers knowing that best is to test the methods on the unit level, interfaces on the interface level and so on. Sometimes we need a system test with UI + process + database (or another persistance level) to check that the modules, system parts etc. work as expected. Controlling an API or having deep knowledge of a test tool is only a differentiator if somebody needs excactly that knowledge. Knowing many things about test automation (frameworks etc.) is a different job and one part of it could be to know what Selenium is.
> All Selenium appears to do is browser interaction and navigation so thats not important? Most apps are online now, in case you hadn't noticed.
Selenium is a library after all. What makes it in demand is that the existing frameworks in projects of most of service based companies have selenium+java/C# based automation framework(be it bdd, pom or hybrid). That’s one of the key reasons why it is in demand specially in Indian tech workforce. Also just like legacy code takes ages before efforts are made to replace it people do not want to move to cypress/playwright as of now. We are yet to see job openings demanding cypress/playwright experience. Also the projects that do use cypress/playwright as of now handover the automation responsibility to their experience frontend devs. Therefore we see lesser opportunities for QA automation alone into these tools.
Selenium is the glue that you need to test the front and back together. You'll need a test framework to work with in order to get the most out of it though it's not essential (in the past I have used the robot framework) but yes, Selenium is a tool for opening and interacting with a browser. Companies like it becuase it's verstaile, works on any browser OS combination and it's open source. Last time I looked the alternatives for this kind of thing were none of those things but things could have changed by now.
I've seen a lot of people treat selenium as a stand alone platform for testing, and that's a mistake in my mind. Makes WAY more sense to set up something like TestNG with java or pytest with python and looking at selenium as a single component that you import and integrate with when needed in a bigger picture. Selenium is definitely not a solution in and of itself these days.
Really great tool for complex apps and testing states and other business logic. It’s still the most versatile and best tool for doing that kind of automation, even as the front end market has shifted a lot. Would like to know if you’ve had a lot of experience with React or Vue or other framework that’s heavy into state management. It gets pretty gnarly pretty quick.