A brief introduction to Selenium WebDriver, and some simple guidelines to evaluating how it can help you!
Automation with Selenium WebDriver
The purpose of this article is to shed light on the thought process behind adopting Selenium WebDriver as a testing solution for your web application. I will address the 5 W’s. Who, What, When, Where, Why?
What is Selenium WebDriver?
Simply put, Selenium WebDriver is an interface for automating web browser navigation and interaction. It can verify and check all of the functionality of your web app by interacting directly with the page by clicking, entering text, scrolling, and much more!
Currently, the popular browsers (Google Chrome, Mozilla FireFox, Edge, etc.) create drivers for their browser. These drivers interface with their respective browsers so they can be controlled. Thus, steering the browser through your web app.
These drivers must interface with Selenium WebDriver. “Why?” you ask? So that when you issue a command through the driver instance, it behaves the same way in each different browser. Your code is now browser agnostic. You can command all the browsers to do your evil bidding with the same code!
Why should you use Selenium?
Manual testers are the best. They can catch the edge-cases and the wonky behaviors of your app while you’re developing it. They can create useful, reusable test cases that make for great regression testing when your app becomes large.
I think it’s safe to say, however, that repetition gets repetitive. You don’t want to bore your manual testers into looking for a new job. You want them to push exploratory testing, not repeat the same tests every time you have the need to do a regression of a feature.
Selenium is amazing at repeating repetitive things! When properly scripted, a Selenium test can run through a flow with ease. You can verify and check everything a manual tester would, save for how the website actually looks. So when it comes to repeating repetitive things Selenium can repeat repeatedly!
When should you start using Selenium?
Answer? When regression testing slows down development.
That might just be my opinion, but it’s when it makes most sense. Once the regression workload is so large that even developers get pulled into manual testing, it’s a sure sign you need to take a peek at Selenium automation.
The idea is to automate your manual test cases in a prescriptive manner using Selenium. This is going to vary wildly and will take some trial and error until you find what works for your organization.
As your automation suite begins to carry some of the weight of regression testing, your developers can go back to developing and your testers can go back to testing!
Who should write your Selenium scripts?
If you’ve made it this far, you’re probably wondering “If my manual testers are already busy, how do we even begin to automate all these test cases?!”
While they are often called Selenium ‘scripts’, they typically exist as their own code base. You’ll probably need to put an ad out for an automation developer!
“But wait Jason, I already have developers! Why should I hire another one just for this?” Depending on the organization of your developers, and what methods you use to deploy and manage your app, you might be able to push automation duties onto your developers. However, I like to follow the same logic behind code reviews. You wouldn’t really want a developer merging their own code, so why would you want them to automate it? Having more eyes on your app in different capacities is just good practice!
Where should this development take place?
Kind of an odd question, right? In-house of course! Right? Team maturity, resources, time, budgets all factor into this question. A definitive answer
To the point, it will probably live in your favorite Version Control System (VCS)! You’ll update and version this just like the other software you’re developing. It is subject to code review just like any other project!
You can develop the automation with your existing developers since they are a bunch of smart cookies. Or you can hire some pretty rad professionals to work with your team to create a solution that works for your project! Firing up the process from scratch might take more ramp up. However, leveraging staff augmentation will give your implementation of Selenium a jump start to ease the burden of regression sooner rather than later!
Alright, I’m sold! What’s next?
Well. Now you get to pick your flavor! Which language would you like to develop your automation code? You have choices!
A quick search yields the following languages that Selenium WebDriver is available in at the time of this article:
- Java
- Python
- Ruby
- C#
- JavaScript
- Perl
- PHP
One could argue that the two most popular languages are C# and Java. In my experience, most coding examples are written in either of these two languages.
This is just the introduction to my series on Selenium WebDriver! In my next article, I’ll be covering the performance differences between a Selenium script written in Java and C#.
What’s next?
- Selenium is written in Java. Will that matter in terms of performance?! Find out on my next blog article “Selenium WebDriver: Java versus C#. Who has the need for speed?”
