Ultimate Selenium WebDriver Guide for Test Automation with Robin Gupta

In a land of testers far and wide they journey seeking answers, seeking skills, seeking a better way through the hills they wandered through treacherous terrain but then they heard a tale of podcasts they had to obey O the test Kill Animation testing podcast Guiding testers with our nation awesomeness from ancient realms to modern days they lead the way O the Tusculon O testing podcast with sweeps and lyres the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding testers, showing them secrets to behold O the Cheskill Automation testing podcast Guiding testers with our nation awesomeness from ancient realms to modern days they lead the way oh, the Testkill Automation testing podcast.

Oh, the Tescal Automation testing podcast with lutes and liars the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing us secrets to behold.

Hey, it's Joe. And welcome to another episode of the Test Guild Animation podcast. And today you're in for a special treat because we talking with Robin all about his new book, Ultimate Selenium web Drive for test automation. If you don't know, Robin has been around for a while. He considers himself a mom, which is a manager of managers at office and dad at home. Obviously. He heads product technology and applied AI at Provar and outside of office, he's the international speaker. I've actually saw him at the Selenium conference in Chicago last year. Open source contributed. He has a really cool tool. I thought I've talked to him about before, but I haven't. Tess Zus and obviously an author. Really excited to have on the show. You want to miss this episode, check it out. Hey, Robin. Welcome to the guild.

Hey. Hi, Joe. Thank you for having me at the guild. It's such a pleasure and so happy for the guild and for you.

Awesome to have you. You know, I could have sworn I had you on before talking about testers. And I looked over my notes, I looked over my, you know, my backlog. I found nothing. So I'm already off topic. You know, I always wanted to have you on the show to talk about Test Zeus. So really quick. What is Test Zeus?

It's an open source wrapper on top of Selenium. So it's a small test automation framework specially built for Salesforce.

Awesome. So that's probably. I'll have to have you back to talk all about it, but if you do anything with Salesforce, that's something you should definitely check out and we'll have a link for it in the links down below. All right, Robin, I ask every author before we get into it, why did they write a book? It takes a lot of time, a lot of effort. I know you're very busy, so why write this book?

I think two reasons. So one is like an emotional reason and one is a logical reason. So the emotional reason is like, I always wanted to give back to the community. I'm an open source guy. I've contributed to Selenium and some other projects. So I really want to teach and help the community. That is the first one. The logical reason is very simple. In my experience, the technical books on Selenium are very technical. They assume that you know Java and you know Git and you know, testng and testing and so on, so forth. My book doesn't assume any of that. So we have chapters on all of these topics and ranging from zero to a full 100. Right. So that is the logical reason for writing this book.

Nice. So it sounds like if someone has no experience whatsoever and they say, hey, how do I get into automation? I go buy this book. It'll help them. Is that how it works?

Definitely. That is the idea. That's the target user Persona.

Awesome. And it's interesting because like you mentioned, it's Lato. I think it's nine chapters. The first one is Introduction to Selenium Test Automation and you use Selenium ide. So there's been some not controversy about Selenium ide. I believe it used to be something, then it went away and then they had a new version and now I don't know if they have a new version on top of the new version. So why do you still recommend people start with Selenium ide? And why did you start the chapter up like this?

Yeah, the first chapter in my book or so is actually starting with Selenium ide. That is how I started with it. That is how I got bit by the automation bug. And you know, you can automate some stuff and it runs on its own. It's very magical. Oh, we don't have to do a click. Oh, wow. Magical. So, controversies aside, I think the Selenium community and open source contributors like Todd Tarsi have done a phenomenal job with the new Selenium ide. It's very simple and it's a small app which runs on your desktop using the Chrome plugin platform and you can automate scenarios and get into the world of test automation or browser automation.

So obviously you recommend if someone's just starting off, it just gets them more familiar with the concepts maybe not necessarily. Hey, this is the approach you're going to use for your automation from now until the end using Slim id. It seems like it's a good thing to start off with, just to find out what the principles are and then maybe modify it. Is that why you started with this?

Yeah, exactly. So rather than just pushing people into the well of web driver, we want to give them a slow ramp up time that hey, try this Chrome plugin. You can automate a few browser actions. You can maybe automate a small test case.

Love it. And then I think after that you go into the fundamentals of test automation. I think is chapter two with strategies. So what are some strategies you think someone's starting off with? Automation in general, even if it's not slim, what do they need to know about test automation?

Yeah, I think even before they go to test automation, they should go to testing. So chapter two is a little bit about quality and testing in the modern times of gen AI and all these frameworks and pyramids and whatnot. And then we jump into test automation. So that is the idea there that first focus on the quality, talk to your users, understand the requirements, see who are your stakeholders, what's your scope, what's the environment, test data. Once you have the notion of a test case, a test script, something which is repeatable will help you in regression. Why not let's automate and then we go to test automation.

Why do you think that's important? Because when I started, as you could tell I'm very old for some reason it was more testers using tools to help them with testing. But now it seems like sometimes people just jump. I'm an automation engineer and they don't know testing. I don't know if maybe I'm just an old man going, ah, get off my grass, learn testing. Is that true? Do you think people don't necessarily suffer as a tester anymore, they just jump to tooling?

Yeah, 100%. So in my circle we have this thing. So you would have heard about behavior driven development, pdd?

Yeah.

Have you heard about rdd?

No.

Resume driven development? Just because Cypress looks cool on your Selenium or Selenium looks cool on your resume, people go and jump onto a clue, forgetting all about testing and quality and users and specifications and whatnot.

Absolutely.

It's not an old man thing, it's just a human thing that, you know, focus on the quality. Automation is a means to an end.

Love it, love it. And I definitely agree. So if someone has a better testing background, the automation is going to be better because it's actually going to be adding value.

It sounds like 100% there automated test cases, even though few would be 100x better than 100 test cases which are of low quality.

So if someone's working for a company, do you think the company understands that though? So is it more like someone's like, I just need to do automation because that's what the company wants and so I'm going to sacrifice quality because I'm being judged by I created 100 automated tests or is it a balance where not only do you have to be a good tester, but you need to educate your team on what good testing is.

Interestingly, I think whether it's testing or DevOps or development, all of these need buy ins from other stakeholders. And therefore, let's take the example of quality or testing. I think in my experience the testers are not just supposed to highlight the bugs in the product, but also in the process or humans. So if, let's say I come to you and you say, hey, I just want test automation problem, I would ask you maybe five questions as a tester. So what's your target scope? What's the outcome that you're looking for? What is a good bar of quality for you? Do we really need it today or we're not mature enough to have it for the next three months. So I think those meaningful conversations are required in a lot of big organizations, big teams. Some of that nuance gets lost or people just get driven by a certain tool or a framework, which should not happen.

Absolutely. So once they understand testing, then I know the book is about Selenium, so why would they choose Selenium? I mean, I love Selenium. A lot of groups now, they're like, oh, you should try Cypress is the right tool. Or Playwright. Playwright Slender's dead. Or Cypress is dead, you know, like how do you know then once you know testing what tool to use for your particular situation?

Yeah, so I think in my head there are these three things which would help you decide at a high level. And also it's not just open source tools or open core tools like Selenium and Playwright and Cypress. Even awesome tools like Provar or the others in the market, I wouldn't vouch about them. But nonetheless, I think it's these three things. People, process technology. So when I say people, it's your team, let's say me and you are on that engineering team, Developer QA product manager and my engineering manager are all of us from the same background. Maybe the four people are more JavaScript oriented, but I'm the only Java Galactic and also are application doesn't require a lot of strong cross browser test automation and maybe more component level testing and automation. So let's try webdriver IO or Cypress. Right. So that is the people aspect process. How mature are we? Do we have test cases? We have a few test cases already written in some language unit integration. And do we have the budget to have tools or do we want to go open source because we feel we are strong engineers. And last but not least is the technology, not just your technology or that one app in the whole banking company. How does it align to the center of excellence or those multiple teams who go towards a common goal, who maybe work towards the Black Friday release or something. So these three things can help people decide which technology tool test framework to use rather than just because, oh, Robin said on that podcast we should do Selenium. We should do Selenium.

So Robin, you did say something interesting. I'm not trying to get you in trouble, but you contributed Selenium. You contributed to Tesus Open Source. But you sounded like you said open source is not always the answer.

Exactly.

That seems to be a struggle sometimes because like you said, it depends on your team, depends on your technology. And I love vendors. Sometimes a vendor actually makes sense for certain situations to me.

Yeah. So interestingly, let's take Roman as an example. So the target Persona that we have is for the citizen tester. Now, if we go by Salesforce's definition of multiple roles, we have an admin, we have a developer, we have a business analyst, and these folks deliver the software on top of the Salesforce platform. Now, each of these could be a tester or wearing a tester's hat. And maybe if they've done a few releases, neither are they technical nor do they have the time to go into open source and build all of the test automation framework. So go with the tool, it will get you started very quickly. And some of these tools, for example, Provar is very focused on Salesforce, so you don't have to bother about maintenance and all. But that is just an example. Do that analysis, talk to the team. And in addition to all of this, the budget should be there.

Absolutely. So in the book, it assumes you've done that, you've decided, I'm going with Selenium. So chapter three goes over some basics of webdriver. So what are some basics people need to know about Selenium, I think one of the things you go over is locate a strategy. But are there other things or why is locator strategy so important?

Yeah. So interestingly, for humans like us and you, when we look at a website, let's say the Gmail application, we can see where is the compose button inbox, where are my emails and all. But how do we have an automation screen to take a look at? That UI is through locators. And that is why it is so important. Assume that if I have a blindfold and I'm told to test a website, how helpful I would be as a qa. Similarly, for a test automation script, the concept allocators is very important because it helps the automation script locate elements on the screen and therefore interact with them. So that is one concept. Waiting strategies is another concept. Like if you click on the send button, how quickly the next screen comes up or when you click the submit button on a form, does it take one second? Does it take three seconds? Is your Internet slow? The automation script needs to know when the next state is coming up. So that is another very key concept in test automation.

So you know, for a beginner though, this could be tricky. And I know some of the other newer tooling, I guess the issue is slam is an API and so you could do anything with it. That's what's awesome about it. And you have some other tooling that is like kind of like it's more like a framework where it has built in things where you don't have to build them from scratch. So it seems like locate a strategy. Some of these other tools have things that you don't have to worry about it. But with Selenium you do anything you could do to make it easier then for the locator strategy.

Okay, I think first of all, Selenium apps also did a lot of things. For example, recently we had the nearby locators. So if you are looking at a homepage, we can say click on the submit button to the right of login button. So that makes it simpler. But also if you go to selenium.dev or the homepage of the Selenium Project, Selenium HQ, it says Selenium automates web browsers. That's it. What you do with it is your decision. If you want to build scrapers, test automation, process automation, that's all for grabs. And therefore we provide them tools, for example locators and some of these pieces where the test engineer or automation engineer can fine tune those buttons and does not Assume on the behalf of the process. Some of these other tools make these assumptions and try to make it simpler. But see, it's always trade off between simplicity and accuracy. So it depends. You want to be accurate or simple? Both. Never. Right, right.

And also some tools are very opinionated. Like this is how you do it and you have to force it down the throat of your team. This is how we have to do it now, where if you're more like free flowing and you like to be in control, Selenium gives you that flexibility.

Exactly. I think Selenium was built by engineers for engineers. But these other tools don't believe that.

I think so now I'm jumping ahead, but it just, it's. I think we need to address it. Here is, you know, Selenium, they focused a lot on making it a standard for a long time and so some of the features weren't necessarily updated as much. But then Selenium 4 came out, I think really put it up into the class of where like all the functionality all these other tools started to have. But I'm not sure if that message has been out there. So when you talk about located strategy and things like that. And before we go into like more advanced Selenium techniques, do you think Selenium 4 has incorporated features that people still don't know about that makes it like a modern test tool now or test API?

Yeah, yeah. I'll be very honest over here. Maybe a little controversial is that Selenium has been this very engineering focused open source project. So the marketing has recently started picking it up from an open source perspective and we just now started talking about all these other angles. Hey, you know, let's say we have these nearby locators, you could try them. We have the new bidi. Nobody else does that. Why don't you give it a shot? So we recently started speaking about it as we have built it to a certain stability and now I see that the graph is only in the upright direction. So people will get more and more visibility through conferences like Selenium Conference, through my book, through Joe Quarlentino's podcast. So hopefully we'll solve it.

Absolutely. So once they know the basics, then they jump into some advanced techniques. I know one thing a lot of people struggle with is shadow DOM. And I know tooling like WebDriver IO addresses this fairly nicely. So if someone's just using straight up Selenium, are you still able to deal with things like Shadow doms or what are other techniques they need to know about?

So Shadow DOM is An interesting one. So, as we discussed earlier, some tools, like let's say WebDriver IE, have methods implemented for it as part of the core library, as part of Selenium 4, a lot of those pieces are implemented, but maybe not exposed to the user. So what we could do is add some scaffolding, some more methods in the framework, and then actually handle any of those web elements. Plus, with the advent of bidi and how we are doing cdp, this will just become easier and easier as we go along.

Do you have anything about BIDI in this chapter or advanced LAMP techniques that is even further?

So the journey of the reader in the book is like, get started with testing automation basics, go towards Selenium basics, understand the advanced Selenium techniques, and then boom, we'll have a chapter about the architecture for Selenium.

Yeah, so.

So that they're not intimidated.

Okay, all right, cool. So like they're getting their teeth wet. You know, they're getting like into it and the advanced techniques. But then I think the next. Then like you said, it goes sequentially. So anyone could start from beginner, end up as an expert. So I think the next chapter that everyone struggles with as well is test automation frameworks. Any tips on creating a framework and how to get stuck and building all this stuff before your team even tries using it?

Interestingly, this was something which I faced many years back when I was working with a test automation project and a wise human told me that you don't need to reinvent the wheel, you can go in the Internet. And there are many test automation frameworks which are available for people. For frameworks like Selenite or Etata or even Tezos, there are open source wrappers for Selenium or around it which has these opinionated implementations for language bindings, C Sharp, Python, Java, JavaScript, and for specific purposes like testing and automation. So you can pick one of these. Or if you really want to jump into that deep well of building a framework. The book also covers some fundamental pieces where we tell the reader that this is how you can go about building these blocks and setting up the reusable boxes. Like the ever controversial Page Objects.

Why they controversial? Why are they controversial?

Interestingly, Page Factory or Page Objects came up as a recommendation for emulating the website. For example, we have a login page and it has the first name or username and password and submit button. It was intended that you can model the same thing in languages, in object programming languages like Java as a small object. And if you go by good design practices, each of These would be individually implemented on that Java object. But how people took it was that every web page becomes a page object. So we should have a login page object and a homepage object. If your homepage object has three pieces, all of them should be on the homepage object and we should make that 5,000 line class code. So that's why it is controversial that it's a design pattern or a recommendation. Does it apply to you? That is dependent. But people just took it and ran with it.

All right, so this may sound weird, like, why create an automation framework, as you mentioned, from the ground up? I would think you need to be a developer to do this. A lot of times I see testers that have a testing background trying to do it. And it's not a. I'm not making fun of them, but it's like, if you're not a developer, why are you trying to create a development framework from the ground up? When you have excellent solutions like Webdriver IO, you have Serenity, you have karate, you have all these solutions that are open source. So why do this? If someone's like, all right, I might create a framework.

Let me take an example. If I offer you, Joe, would you like to buy a new car or would you like to use my old car? It runs fine and it gets you grocery.

But humans have this tendency that, you know, oh, no, no, no, no. I'll build my own car. I'm feeling like an engineer today. This is my thing. And I will assemble my own IKEA chair. So that is why a lot of teams and engineers tend to do that without realizing that there is real gold lying outside.

Right. And they could have taken the car and been to, like, Vegas and come back while you're still building your framework. Not having fun at all.

Right, exactly. And people just get stuck in these three months, six months, prints and cycles of. I'm building my own framework. Yeah, yeah, yeah. To automate two test cases.

Yes. Right, right. All right. So another thing people struggle with, then they like, so they have the basics, they have the advanced techniques to create a framework, and they're ready to roll, ready to scale up. And this where I see people crash because, like, they have one or two tests, they run fine, one or two sprints, and then forget about it. It goes downhill from there. What are some scaling tips you have or distributing test tips you have in chapter six?

I think it's very simple. So it's like one of the feedbacks I got when I was growing as an engineering leader is this piece of Feedback that you should crawl, walk, run, fly. So rather than just jumping onto an I will automate the universe, just go step by step. Don't scope all of your hundred test cases automation into like two sprints and don't kill yourself because the free gift of maintenance comes with every automated test case. So you have to think slow and steady and over a larger horizon. Also, it's not about not automating all those test cases, but providing the economies of scale or saving that time with that automation. So in simple terms, crawl, walk, run, fly, go step by step, scope it out. It's not a one time in lifetime kind of a chance. Run it for a while, show the results, then grow further. And second is retrospect and introspect. For example, whatever you built out, just like how you would run a development sprint, do retrospectives after every few sprints and understand what can be improved. Maybe there is some tech debt or there is some code which can be updated or maybe the code coverage is not there so it should be plugged into sonarqube and other tools. So those are some of the tips which I would recommend people for scalable and stable test automation.

Do you cover anything with test data? Because I know sometimes that limits people how they can scale or even they have dependencies like test one needs to run before test two they have these weird combinations is that something new address at all?

Something which is highlighted in the book is also test data and the other like a stepbrother of a test environments. So both of these need to be managed precisely not as part of the framework but as part of the CI CD pipeline. For example, the same I'm using should be used by the developer or the product manager or the person who's doing the final sign off. Similarly, for environments, not all tests need to be done on each environment. For example, on the device sandbox or developer local setup, either the unit test cases on the SIT system integration test. Run the integration test. It's in the name. There is a hint in the pre production environment, do your QA and to end test cases try to make a pyramid or an ice cream cone or a rhombus. But don't just mix up everything.

All right, so my next chapter I'm drawn to because I actually started my career more as a performance test engineer. I did functional automation, but I did the majority of thing with loadrunner and performance testing. So this next chapter is SaaS and non functional test automation. What I see as a trend and I'm not sure if you see this or you cover this is a lot of people are now able to leverage their functional test to get some sort of non functional benefit like performance and security. So what does this particular chapter address then?

Yeah, so interestingly it has these two pieces. So for example, one thing is that the SaaS test automation software as a service test automation is not the same as your B2C E commerce website test automation. So throughout the book we've tried to maintain this theme that don't do test automation just for the heck of it. Do it as per the scope or the target environment. And to your question, the non functional test automation is like, how do I put it? It's a gray area. You can use your functional tests for some performance testing, but it should be only some. You should not be scaling up all your end to end. Let me check out a book from Amazon with a thousand test cases down Amazon today. That doesn't make any sense. So we should do it as per the test type, as per the environment.

No. Great advice. So definitely check that chapter out because I think it goes over the right approach for sure. All right, so the next one is, you know, once again you go on on X and used to be Twitter, different social media platforms and you have people like BDD don't use it. But I've used BDD the right way, I've seen it used the right way and people benefit from it. So where do you. You have a whole chapter on BDD with slim. So obviously I assume you believe in BDD or like what are some things you go over in this chapter?

So interestingly, just like Selenium is not strongly opinionated and it gives you the tools to perform something. The idea of all these chapters in the book are that these are tools for you to use. We're not trying to say that. Oh, since you are the reader of this book, you must use bdd. Check it out, try it out if you like it. If you want your product manager to write some non technical test cases, you can try bdd. But everybody is an engineer on the team. Just skip that chapter, go to the next chapter about AI.

Absolutely love it. All right, so I think that one of the last chapters is new features in Selenium 4. We already touched on Bidi some other things. I think you have a Selenium test driver manager now or something that's able to handle the drivers for you. So what are some other features that you cover?

So interestingly, the big ones are these two. So one is Bidi and the architectural change in selenium 4 how it has become a W3C specifically and how it ensures that your test will run fine across all the browsers in like real browsers, not like one of those fake made up browser engines. So that is one big one. The second big chunk is Selenium Manager as you highlighted. So earlier if you had to let's say run Selenium on your local with using webdriver, you would have to actually set up the browsers, their drivers, the page jar and everything. But with Selenium Manager and thankful to the awesome work by Bonnie and think this is all just prepackaged with webdriver jars and everything so you can get it going in two commands or maybe lesser. In addition to that, as I mentioned there are nearby locators and also Selenium Grid gets a mega update where you can also use the Y die and other pieces to have a much more scalable grid implementation.

Love it. So definitely folks listening, we'll have a link to the book for sure. So Robin, I know the book, I think it just came out the end of February, maybe March, early March. But have you gotten any feedback around this yet that you were surprised by or like oh wow, I'm glad that that helped you.

Very interestingly, a close friend who is who was not from Test automation but from DevOps, he passed on some feedback. One he could relate to those concepts so it was a happy surprise. And second, going through the book he mentioned that it actually delivers on some parts of that promise that it doesn't assume that the reader knows Selenium or knows Testng or these parts. Even somebody who's from DevOps or development or isn't a citizen tester, they can go about reading the book and become acquainted. Not an expert in Selenium.

Absolutely. So I'm going to make this one of my go to resources for people that ask me, hey Joe, I'm a manual tester. I know that's a controversial term as well. Or maybe let's just say someone that says I want to learn more about automation, I can give them this book. So Ari, Robin, before we go though, is there one piece of actual advice you can give to someone to help them with their Selenium automation efforts? And what's the best way to find or contact you or get their hands.

On this book so they can get the hands on the book from the website of Amazon or from my publisher. So if you go to Amazon.com or Amazon.in you can type ultimate selenium webdriver for test automation and you can get the book as a physical copy or an E copy. And the one key takeaway advice is that folks don't get afraid. A lot of people who might talk to they're like, oh, this sounds complicated. Do I have to learn about locators in HTML and whatnot? Don't be afraid. Fear is just the first stage. Success is right after, so people should focus on that.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a498 and if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them.

So that's it for this episode of.

The Test Guild Automation Podcast. I'm Joe. My mission is help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the the world, we'd love to have you join the fam@test guild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the guild community, I'd love to hear from you. Head on over to test guild.info and let's make it happen.