Learn How to Install Java and Selenium WebDriver

Install Java and Selenium WebDriverSteps to install Selenium WebDriver

Here are the steps needed to install the various components needed for Selenium WebDriver.

 

 

Step 1: Install Java

Download and install the Java Software Development Kit (JDK) here

install Java jdk

Select and download the correct JDK version for your operating systeminstall selenium webdriver

 

O

Once this installation has been downloaded and installed, open your command prompt and type java -version to confirm the correct Java version has been installed.

confirm java version

Step 2-Install Eclipse

Download the latest version of Eclipse here.

download eclipse ide

Once the file has been downloaded, double click on the file to install Eclipse.  Select Eclipse IDE for Java Developers.

install eclipse IDE

Click on the Install button.

install selenium webdriver

Accept Terms and Conditions

accept terms

The installation will begin.

When the install is complete, click on the Launch button.

launch eclipse

Step 3-Download Selenium Java Client WebDriver

Download the Selenium Java Client WebDriver here.

selenium java client

The download file will come as a .zip file.  You can create a folder on your computer called: C:\Selenium and extract the contents of the download there.  This will contain all the needed files that will be used to configure Selenium.  Once you extract the files it will look like this:

selenium webdriver install

Step 4-Configure Eclipse with Selenium WebDriver

Go to the location where you extracted the zip file.  It will contain an executable called eclipse.exe.  You might also see a shortcut on your desktop that looks like:

eclipse shortcut

Double click on the Eclipse shortcut and it will launch Eclipse. You can use the location listed, and click on Launch.

launch eclipse

Once the screen is launched, click on Create a New Java Project

create java project

The following window will appear.  For the project name you can call it myfirstproject.  You can use the other defaults listed and click the Finish button.

learn selenium

The following window will appear.  Click on the Create button.

The following screen appears:

how to install selenium

Right click on myfirstproject and select New and then Package.

setup selenium

The following window will appear.  Name the new package mypackage and click on the Finish button.

selenium automation

Right click on myfirstpackage and select New then Class

selenium automation jar

The following window will appear.  Under name enter myfirstjavaclass and click the Finish button.

install selenium webdriver

For the next step, right click on myfirstproject and select Properties

selenium java webdriver

On the properties window, select Java Build Path then Libraries tab then Add External JARS…

java selenium learn here

The JAR Selection window will appear.  Go to the location where you installed the Selenium files on your computer.  Mine is installed at: C:\Selenium.

how to configure selenium webdriver

Double click on the libs folder

selenium configuration settings

Select all the files and click the open button.

selenium files

You will see all the files you selected displayed.  Click on Add External JARS.. button again

how to configure selenium webdriver

The JAR Selection window will appear.  Select all files there and click on Open.

setup selenium webdriver

On the Properties window, click on the Apply and Close button.

selenium web automation

You will now see the Referenced Libraries displayed.

selenium webdriver files

 

The Selenium WebDriver configuration is finished.  I hope this information has been helpful.  Don’t forget when you create a new project, you will need to import these files again.  In order to run your scripts you will need to determine which browsers you plan on using.

You can click here to learn how to setup the different browsers.

Selenium: Learn More

What is Selenium

What is Selenium?

If you are in the software testing profession, one of the most often asked questions is What is Selenium?  Simply put Selenium is an open sourced software testing code.  It is becoming more and more popular everyday, and it is fairly easy to learn.  It was created by Jason Huggins in 2004.  He had a need to perform testing on a web application, so he decided to create a JavaScript based tool that could simulate manual testing activities.  The original name was JavaScriptTestRunner.  I am going to walk you through the process learning more about the code and the pros and cons of leveraging this capability.

Benefits

  • Open sourced software testing code allows anyone to use this tool with no software licensing costs
  • Is used to test web based applications
  • It has a very strong community because many software testers use it
  • It can be used with popular software programming languages such as Java and Python
  • Runs on many different browsers across different operating systems
  • Can easily be integrated and leveraged with other tools

Disadvantages

  • Only used for web based applications, so it will not support automation of mainframe or AS400 applications
  • Is supported by the community, so there is no central company that owns the code or provides updates

Components

  • Selenium WebDriver: is a collection of language bindings to drive actions within the web browser.  If you need to create a series of web based test automation scripts you will need to use Web Driver. If you want to learn how to install Java and Selenium WebDriver click here.
  • Selenium IDE: is an integrated development environment.  It is the simplest component of Selenium that allows you to perform record and playback of test scripts. The Selenium IDE is a Firefox add-in that is easy to install and setup.  This helps to uncover defects quickly when you want to use repetitive processes to ensure that nothing breaks when software is changed.  This tool should only be used to quickly record and prototype things to make sure it is going to work.  It will be helpful to know some simple concepts of HTML, JavaScript and DOM(Document Object Model) in order to have a solid foundation on how the tool works. If you need more complex scripting, then you will need to use Selenium Web Driver.
  • Selenium Grid: Is a tool that enables parallel test execution across multiple machines and browsers at the same time.  This saves a lot of time and helps you get through large regression suites.

Click here for additional information on Selenium.

There are also some Big Changes in Selenium 4.

For the official website you can visit Selenium HQ.

 

Creating a Bunch of Test Automation Scripts Is a Waste of Money

It is extremely important to develop a strategic plan when creating test automation scripts.  With the push towards Agile and DevOps the mindset has become to automate as much testing as possible.  While that idea makes sense, it is important to determine how much test automation is needed.  Part of the problem is that those who are managing Agile or DevOps teams have a really different mindset, and they really don’t understand basic testing principles.  Instead of taking the time to understand, they force their understanding and push test engineering in the wrong direction.

Test Automation Planning

Test automation is certainly critical for Agile and DevOps.  There are things that can and should be automated but before that is done, a few questions must be asked:

  • How many times are these test automation scripts going to be executed?
  • Is the code stable or is it going to change a lot over the next several sprints?
  • Has the test been executed manually and has it passed successfully?
  • How much time will it take to maintain the test scripts?
  • Do you have the right resources to build and update the test scripts?
  • What type of tools are you going to use?
  • What type of framework are you going to build?
  • How much does the test automation software cost?

These questions will help lay the foundation of your test automation planning.  The next step will be to identify the number of test cases that need to be automated.

Testing That Should Not Be Automated

Here is a list of test cases that should not be automated:

  • Test cases that will only be executed a few times
  • Test cases that require human touch, for example review of a customer bill
  • Test cases that require a third party billing system such as a payment gateway that doesn’t have a test environment
  • Test cases were the code is unstable and is constantly changing

Test Case Quality

Test automation scripts help with providing test coverage across applications.  This allows faster deployments because it doesn’t require manual testing.  However, if you create hundreds of test cases and those never identify any defects, is it really worth maintaining and running those over and over again?  Probably not.  The test cases that are automated should be able to capture defects.  Therefore, it is important that you have some really sharp manual testers who can think through the testing scenarios and identify problem areas that need attention.  Without that system knowledge, you will not capture defects and it will not be a good use of your resources.

Return on Investment

It is really important to understand how much cost is involved in creating automated tests.  If you create thousands of them, how much is it going to take to make changes on those when the GUI or back end systems change?  If it is your department or team, as a manager or employee, you really need to be able to answer this challenging question.  At every organization, I make sure that I calculate the ROI.  There are a few ways to do this.  First, you roughly need to know what is the cost of a member of your team or the average rate per contractor or employee.  Most organizations will have that already.  Second, you will need to determine how many scripts are going to be automated and how many times are they going to be executed.  Third, you need to know how much time does it take to execute those test cases manually.  Fourth, once the test cases are automated, you need to know how much time does each one take to execute.  These items will at least give you a basic ROI.  Most ROI numbers are somewhere between 6-12 months.  Anything over a year, probably isn’t worth it.  There are other variations that are more complex, but this will at least get you started.  Knowing this information is certainly powerful, and it will help justify the expense for having automation engineers.

I cannot stress the importance of doing these basic steps.  With Agile and DevOps, everything tends to be rushed.  Perform this basic analysis first and spend a little time up front to yield large returns in the long run.

Role of an Agile QA Engineer

Agile QA EngineerAgile Software Testing has literally transformed the role of an Agile QA Engineer.  There are several key differences which software testing organizations will need to adjust in order to effectively operate with Agile.

Documentation:  It isn’t practical within Agile for the Agile QA Engineer to have lots of documentation.  Don’t get me wrong, there does need to be sufficient documentation for the QA Engineers to do their job well. If a developer tries to convince you that the Agile Manifesto doesn’t require documentation, Houston we have a problem!

  • In terms of requirements, there needs to be enough documentation that the Agile QA Engineer knows how the system is supposed to operate.  In my team, we currently use a 1 page document that will provide that information for each story.  It really does help the agile testers know what is expected so they can adequately plan.
  • For the Software Test Plan, it isn’t necessary to go through all the hoopla of creating a massive plan that nobody will read or follow.  A one page document will be sufficient.  I encourage the creation of the one page plan because it forces the agile tester to think about what testing is needed.
  • For the testing sign off a simple email will suffice.

Test Automation: One of the hottest topics naturally is test automation, especially within Agile software testing.  Test automation without a doubt is critical.  However, there needs to be a strategy that is going to work.  In previous organizations, I have built world class automation teams.  We had thousands of automated test cases within our regression suites.  Were all those tests necessary, probably not.  Was it expensive to maintain, absolutely!  I believe having a centralized automation team that can build and execute the automation tests is most effective.  The team prioritizes the work based upon the needs of the various agile teams.  I have found this to work most effectively.  I usually recommend that the agile testers execute the tests within the current sprint and once those have passed, they can hand that off to the agile team to automate and put in the regression suite.  Having an Agile QA Engineer do both the functional and automated tests within a given sprint is extremely challenging and often the functional testing gets done and the automation gets put on the back burner.

Performance Testing: Another challenge is system performance.  If automation takes a back seat, then performance testing is usually behind that.  In order to deal with that challenge, having a centralized performance team will help.  Usually 2-3 performance engineers will be sufficient.  I encourage a very close look at performance testing within the Agile context.  If you don’t need it, don’t do it, if you need it, you better do it.

UI versus Web Service:  Agile software testing requires some fundamental changes in terms of how things get tested.  More and more agile software testing is taking a closer look at web service testing.  It is a critical component that can find a lot of defects.  The need for agile teams to focus on spending more time in this area is due to the amount of applications that are using API’s to transfer information.  It is a lot quicker to run hundreds of transactions through an API versus through the UI.  Agile software testing teams who are able to make this transition are simply more effective.

Let’s face it, transforming your software testing organization is going to be very challenging.  Agile software testing is extremely challenging.  The key is to have a strong team who is flexible and is adaptable to constant change.  The teams that can do that most effectively will be successful.

Role of Agile QA Manager

QA Agile Manager

If you are an Agile QA Manager your role has probably changed a good bit from the more traditional Waterfall methodology.  It certainly requires a bit adjustment, but if you are able to make the transition, it will certainly help ensure your organization delivers high quality software.  Chances are your involvement will change and it will require a different mindset and approach.  Here are a few items that will make an Agile QA Manager successful:

  1. Documentation: Certainly this is a huge change from waterfall.  In typical waterfall the documentation is a lot heavier and that includes requirements, test plans, and design documents.  Documentation is important and contrary to what you might hear, it is still an important aspect of Agile.  I still encourage my team to create a small requirement document for each story and that really helps the QA testers.  For QA, I encourage creating a 1 page QA test plan and that helps development and product owners understand what is tested and ensures everyone is on the same page.  In terms of QA sign off, I simply require an email stating that QA has signed of on the story and release.  As an Agile QA Manager, I encourage you to keep things simple and lean especially around the documentation.
  2. Collaboration: Collaboration within Agile is extremely important and it is one of the most important elements of having a high quality product.  It is important for the QA tester to work hand in hand with the BA, Developers, and other QA resources.  Collaboration helps to get the best information and gain a solid understanding of the product in order to be able to test the application more effectively.  Where possible, I encourage the QA resources to sit with the other members of the Agile team.
  3. Automation:  It is important for automation to occur, but it needs to be done efficiently.  Maintaining automation test scripts is expensive so it is important for the Agile QA Manager to take a very close look at the amount of automation in place.  I have found that the automation is most effectively done by dedicated automation resources and I have set them up as a separate team.  Many teams have the QA engineer perform both functional and automated testing, but I have found that when push comes to shove, the automation takes a back seat and isn’t a priority.
  4. Performance:  Performance testing is important and needed.  There might be applications that need more performance testing than others, so a one size fits all model doesn’t necessarily work.  This is where the experience of the Agile QA Manager comes into play, so if you think it is needed, then certainly the effort must be there.  I have also setup a small team of performance engineers that sit outside the agile team and that has worked well for me.
  5. Level of Involvement: It is important to know what the QA engineers are doing and what is being tested however sometimes it is important to take a back seat not necessary get involved in the nuts and bolts of the daily activities.  Chances are high that you will get involved when there are escalations and issues.
  6. Champion of Quality: While it is true within Agile that Quality is the teams responsibility, you need to ensure that across the organization, you are personally involved in helping to build quality.  Things like documentation and testing are important and should be consistent across all the agile teams.  The better information your team has, the chances are higher they will find the issues before they hit production.
  7. Metrics:  As an Agile QA Manager, metrics are your best friend.  It will help you pinpoint when there are issues and help prevent production disasters.  I encourage you to place a strong emphasis on metrics so you base your decisions of quality versus gut feel.

I hope this information has been helpful and I encourage you to closely take a look at all of these items so you can become a more effective Agile QA Manager.

If you are looking for more additional information on Agile roles you can find additional information here:

Role of an Agile Development Manager

Role of an Agile QA Engineer

Role of an Agile Business Analyst

Agile Software Testing Transformation

Agile Testing TransformationAgile Software Testing has literally transformed how organizations test software.  There are several key differences which software testing organizations will need to adjust in order to effectively operate with Agile.

Documentation:  It isn’t practical within Agile to have lots of documentation.  Don’t get me wrong, there does need to be sufficient documentation for the agile software testers to do their job well. If a developer tries to convince you that the Agile Manifesto doesn’t require documentation, Houston we have a problem!

  • In terms of requirements, there needs to be enough documentation that the tester knows how the system is supposed to operate.  In my team, we currently use a 1 page document that will provide that information for each story.  It really does help the agile testers know what is expected so they can adequately plan.
  • For the Software Test Plan, it isn’t necessary to go through all the hoopla of creating a massive plan that nobody will read or follow.  A one page document will be sufficient.  I encourage the creation of the one page plan because it forces the agile tester to think about what testing is needed.
  • For the testing signoff a simple email will suffice.

Automation: One of the hottest topics naturally is test automation, especially within Agile software testing.  Test automation without a doubt is critical.  However, there needs to be a strategy that is going to work.  In previous organizations, I have built world class automation teams.  We had thousands of automated test cases within our regression suites.  Were all those tests necessary, probably not.  Was it expensive to maintain, absolutely!  I believe having a centralized automation team that can build and execute the automation tests is most effective.  The team prioritizes the work based upon the needs of the various agile teams.  I have found this to work most effectively.  I usually recommend that the agile testers execute the tests within the current sprint and once those have passed, they can hand that off to the agile team to automate and put in the regression suite.  Having a tester do both the functional and automated tests within a given sprint is extremely challenging and often the functional testing gets done and the automation gets put on the back burner.

Performance: Another challenge is system performance.  If automation takes a back seat, then performance testing is usually behind that.  In order to deal with that challenge, having a centralized performance team will help.  Usually 2-3 performance engineers will be sufficient.  I encourage a very close look at performance testing within the Agile context.  If you don’t need it, don’t do it, if you need it, you better do it.

UI versus Web ServiceAgile software testing requires some fundamental changes in terms of how things get tested.  More and more agile software testing is taking a closer look at web service testing.  It is a critical component that can find a lot of defects.  The need for agile teams to focus on spending more time in this area is due to the amount of applications that are using API’s to transfer information.  It is a lot quicker to run hundreds of transactions through an API versus through the UI.  Agile software testing teams who are able to make this transition are simply more effective.

Let’s face it, transforming your software testing organization is going to be very challenging.  Agile software testing is extremely challenging.  The key is to have a strong team who is flexible and is adaptable to constant change.  The teams that can do that most effectively will be successful.

If you are looking for more additional information on Agile roles you can find additional information here:

Role of an Agile QA Manager

Role of an Agile Development Manager

Role of an Agile QA Engineer

Role of an Agile Business Analyst