Way to Selenium 3.0

 

Selenium 3 is on its way to be shipped. Simon Stewart (Selenium Project Lead) along with Applitools has given a sneak peek about Selenium3.0 on 25th May 2016. The Webinar was just great as all other presentations by Simon Stewart. I have identified few points and will try to summaries in this blog post-

Main aim for Selenium 3 is to be – “a tool for user-focused automation of mobile and web apps“. this one liner explains it all about Selenium 3 . So they are going to focus on automation of web and mobile apps only (No support for any other kind of application). For Selenium 3, They have primarily worked on making the technology behind Selenium as stable and capable as possible.

For understanding the changes happening in Selenium3, you really need to understand how selenium has been evolved since the time Selenium-Core was released. During this blog post, I will be going  through following points-

  1. The past of Selenium project – how it evolved
  2. Where is Selenium 3.0
  3. User visible changes
  4. Back-end changes

Evolution of Selenium  – Json huggins from throughworks has created a javascript test runner which was capable of injecting Javascript in html pages and perform the required action. User need to create their script in html which is not really a programming language. Due to JavaScript’s same origin policy, user was not able to perform action on the different domain (websites). Then RC came in picture, where your script can actually communicate to a proxy server(RC server) and trick your browser to believe that all the requests are coming from same domain. It was really hard to maintain the Selenium RC/Core tool for the Selenium developer, so they have started working on creating a standard api which can perform all action required on a web page irrespective of the language in which scripts are written.

Simon Stewart then discovered WebDriver api which works on JSON wire protocol over http, and don’t have any language specific dependency. Then this api was wrapped in to language specific bindings to support multiple languages and this was called Selenium 2.0

Where is Selenium 3 – There are two level changes; back-end level changes and user visible changes.

User visible changes

  1. Selenium Core would completely be removed.
  2. Selenium RC would be deprecated, there would be no active development to support Core or RC except the very urgent fixes.
  3. The RC api would be backed by WebDriver, so you can execute your existing RC script (WebDriver is recommended for all active development for new scritps)
  4. Client bindings for other languages except for JAVA are still same
  5. Using WebDriver after quit() would be now an illegal State Exception
  6. For mobile users, the Selenium 3 will be hosting a suite of tests to facilitate interoperability between the many different projects available (i.e. Appium, ios-driver, Selendroid etc.) that are extending the WebDriver API to also cope with mobile.
  7. New Java binding structure for Selenium3 is as follows-
  • Selenium – JAVA : just the webdriver classes
  • Selenium 3 server : Lighweight, command line compatible remote server
  • leg-rc : the old selenium client side classes, WebDriverBackedSelenium, Remote end point for Se3 server

As there would be no support for RC and core, existing scripts would be executed by leg-rc’s “WebDriverBackedSelenium”. Selenium RC server would be replaced by Selenium 3 server which would be command line compatible that means you can access its features through command line. it would really help in continuous integration. Selenium3 server might also have capability to hook in to already opened browser windows.

Backend level changes – Due to support for many browsers by Selenium 2.0 , it was really hard for developer to fix selenium specific issues. For example fixing an issue for one browser (chrome) trigger some other issue for different browser(Firefox). The reason for this inconsistency is that every browser follows different approaches for Xpath engines and other browser mechanism. So Selenium has come up with W3C standard and asked every browser owner to follow these standard while implementing browser. Selenium developer community has also recommended every browser vendor to own the drivers as they are more familiar with their browser. So apart from these following can be changes from back-end side-

  1. Migrate all drivers to use the status strings rather than status codes in responses
  2. All actions to have a single end point for JSON wire protocol service
  3. Migration to netty or webitt server

There is no changes in terms of additional features. They are targeting to have new features specific to mobile in Selenium 4.0. Selenium 5.0 would be completely W3C compatible. Selenium3 and Selenium4 would have interoperability i.e. client bindings of Selenium3 can communicate to Selenium 4 server and vice – versa.

If we look in terms of stability and back-end changes for Selenium , it is a big change. That is why they have changed a major version from 2.0 to 3.0

The old versions will still be available as a separate download, but active development will cease, except for very urgent fixes.

Hopefully , it would be available to download on official Selenium site. I hope i have covered all the features and points related to Selenium 3, feel free to add in comments if anything is missed. 🙂

EDIT 1 : For Q&A session with Simon Stewart during this webinar, please refer to comments of this blog post. 🙂

EDIT 2 : Selenium 3 beta is now officially released, please visit my latest blog – Selenium 3: Firefox with Gecko Driver

Advertisements

Symptoms that your mobile automation is going to fail

Smartphone users are increasing every day and mobile world is growing so rapidly. People now share and access mobile apps more frequently than web apps.

Now talking about their creation, release cycles are so quick that you have to do a lot of work in testing product and that too should be quick. What choice we left ? Automation!. But are we really utilizing that in good manner or we are just making simple things too complex by introducing automation.

Based on my experience their are few symptoms which indicates that you are going towards failure in mobile automation. Agenda for sharing this info is to make you enable in judging whether you are going on right track or not.

So be aware of following 10 symptoms which might lead you to failure if you will not find alternative for them-

  1. Deploying the build (APK/IPA) is a manual process– If you are still doing it manually, stop it. Mobile automation should be as smooth as automating a web app and accessing it through a browser. To speed up the process this part of automation should be automated. There are several tools e.g. Jenkins, Team City. You can refer to my blog Continuous integration with Jenkins in 5 minutes for Continuous integration setup.
  2. No Process where test can execute 24/7 – In the agile world, release cycles are too quick and a tester hardly get some time to perform Regression, functional testing for each feature. You should have a process where your automation test can be triggered anytime and can give you quick validation results. You can achive it by setting up your own mobile devices cloud, or you can use existing paid services like Saucelabs, Testdroid cloud etc.
  3. Scrolling the device screen is co-ordinate based – If this is the case it is very hard to stable your test. As an automation developer, our primarily goal is to make sure that a test can successfully executed on any device of any size. So make sure all actions are object based rather than co-ordinate based. your script might not work for a device with different size.
  4. Wasting more time in stabilizing test rather than building them – It happens when we start creating script, we don’t really realize the factors like – locator strategies, target devices, screen sizes, complex actions involved. As a result, after certain point we waste our time in making current script stable and cant really look forward for new creation. So advice is before starting a project do a little bit of POC(proof of concept), identify the complex situations and take care of them from the starting itself.
  5. You can’t remember the last time when your tests ran successfully – I have seen such situations that when people have small numbers of cases, they have a control to easily identify the false failures and modify the script accordingly. then slowly false failures keeps growing up as the number of cases increases. I would say don’t let you get into that situations. Take each false failure seriously and try to handle all exceptions, so that you can have confidence in your scripts when it comes to releasing the app.
  6. Using indexes at too many places to identify the elements on screen – If you had worked on selenium, you might related when we create xpath based on location in html DOM, It is similar to that. Avoid using indexes in your locators. Mobile app web views, text box’s positions might change in future and you will again end up with modification of scripts.
  7. Using Image recognition or OCR extensively for identification – I have seen many times, people uses OCR or image based technique for identification of elements on screen. Chances of changing the UI design in mobile app are very high. Sometimes not the design but the images might get changes with minor pixel size changes and you need to replace all images for image based identification.
  8. Working for several months but have only dozen cases – A manual tester always try to create test-cases where he can achieve coverage in minimum cases, which result in few complex cases. When we take them for automation, we don’t really divide in to many smaller meaning full cases and start creating complex work flows. I suggest to break cases in smaller one, so that by using parallel execution you can minimize the execution time and get the more effective visibility in terms of coverage. So its good to have many small test scripts rather than few complex scripts.
  9. Running the same script on different size devices, never works on first try – Primary part of testing a mobile app is to test it across multiple devices and screen sizes. If this is not happening in single attempt, means you are not really taking care of all possible devices and screen sizes. You end up modifying your script as soon as you run the script on some new devices. So its advisable to be aware of device scope and functionality future in advance. Be in touch with business analyst is very important
  10. You are not controlling the targeted devices and versions – This is one of the most important aspects in terms of infrastructure for mobile script execution. As an automation engineer, you should be responsible for handling devices and their versions, installing apps in those devices. If someone else is doing it then you should be in sync with that team.

If you are facing anyone of above mentioned problem, start implementing best alternative. Lets not hamper your app quality and focus on being efficient in testing. Hope these point will help you.

If anyone has gone through some other complex situation in mobile automation, feel free to add your symptom in comment 🙂

 

Continuous integration with Jenkins in 5 minutes

When we talk about continuous integration; there are many tools like Jenkins, TeamCity, Bamboo etc. But Jenkins is the most popular because of its numerous plugin and free style configurations for jobs. Jenkins is an open source continues integration tool, which can be used for various purpose as it provides numbers of Plugin. There are two methods for installation and set up of Jenkins-

1) JAVA Web Archive (JAVA War file)

2) Native package

In this blog, I will discuss in details about how you can do Jenkins setup in 5 mins. So be with me and follow below steps-

Jenkins Installation & Set Up-

1) Download the Jenkins.war file from the following URL-http://jenkins-ci.org/

2) JDK 1.5 or above should be installed and a JAVA_HOME variable path should be set in advance

3) Open cmd/bash/shell according to operating system-Windows/Linux/Mac

4)  Locate the folder where Jenkins war file is downloaded

5) Type java -jar jenkins.war and hit Enter

6) Now open browser and hit the URL- localhost:8080

7) If a Jenkins page is opened in browser, that means you have done Jenkins setup

Above steps are for setting up Jenkins. Now Jenkins provide many plugins for various purposes, so you can do other configurations according to your need

Integrating GitHub to Jenkins-

Purpose of this integration is to perform all Github related task using Jenkins. For doing this configuration GitHub should be installed in the system on which Jenkins is deployed.

Please follow following steps for integrating Github-

1) In the Jenkins web GUI, click on Manage Jenkins link and then Click on Manage Plugin

jenkins

managejenkins

2) In the Manage Plugins, click on Available and install following plugins-

  1. a) Github API Plugin
  2. b) Git Client Plugin
  3. c) Git Plugin
  4. d) Github Plugin

 

3) After the installation of above Plugins, Click on Configure System under Manage Jenkins page and set the Git.exe property to its exact path as you can see in screenshot-

git

The Git path shown in the image may vary form system to system configuration.

Note- Above option will be available only if all Git Plugins stated above are correctly installed

4) Save all the configuration settings by clicking on Save button.

Creation of New Job and setting up a Git repository- I will be demonstrating a Github integration for a test project where all the test scripts are on github and Jenkins would be responsible for checking out the scripts and executing scripts on the machine where Jenkins is deployed. Please refer to following steps to do above set up

1) Click on New Job link in the Jenkins Dashboard.

2) Create a free style Software project and click on OK button.

newjob

3) After creating the job click on Configure and select Git under Source Code Management option-

job2.png

Enter a Repository URL as seen in the screenshot, which will be a combination of Username, Password and Repository Name.

Enter a Branch Name if you want to check out the code from a specific branch. If the field left blank, it will refer to Master branch by default.

4)Under Build option select your preferred build method for script execution and write the command accordingly- Please refer to attach screenshot-

build1

build2.png

5) Save the configuration and click on Build Now, if the set up is done correctly your scripts/code starts executing

This is about how you can do quick setup using Jenkins war file. similarly you can do setup using native programs of Jenkins and can create Client-Server modal for same.

Happy Learning 🙂

Multiple Window Handling in Selenium

Today most of the web applications contain multiple navigation links which lead the user to other windows. It is quite possible that at the same time, functionality is performed using two or more windows.  This can be quite a tricky situation although it might sound a simple one. This was something I faced while automating a web application, as working with multiple windows (sometimes even 3-4 windows at the same time) was an essential part of this application).

Selenium WebDriver assigns an alphanumeric id to each window as soon as the WebDriver object is instantiated. This unique alphanumeric id is called window handle. Selenium uses this unique id to switch control among several windows. In simple terms, each unique window has a unique ID, so that Selenium can differentiate when it is switching controls from one window to the other. I will explain it using below example-

public void multipleWindowsHandle() {
        driver.get("http://the-internet.herokuapp.com/windows");
        // Store the first window handle
        String firstWindow = driver.getWindowHandle();
        String newWindow = "";
        driver.findElement(By.cssSelector(".example a")).click();
        //You might need to add wait here to wait for second window to appear
        Set<String> allWindows = driver.getWindowHandles();
        //iterate in window handles and switch to the different window
        for (String window : allWindows) {
            if (!window.equals(firstWindow)) {
                newWindow = window;
            }
        }

        driver.switchTo().window(newWindow);
        if(driver.getTitle().equals("New Window"))){
          System.out.println("You are now on new window");
        }
    }

}

Following is the expected behavior from above code-

  • Visit the page
  • Click to open a new window
  • Switch between the windows
  • Check the page title to make sure the correct window is in focus

First we have stored single window handle and after click operation we are storing all window handle. Once we have all window handle, we are switching to expected window. Important thing to understand here is that method getWindowHandles() returns a Set. A set never store data in sorted manner(its random), so don’t make a mistake of accessing window handles on basis of index.

 

Now when we click on link in above scenario, based on the network speed it might took sometime to open the new window. So following can be some solutions-

  1. Thread.Sleep() could be one solution but we never know the exact time to wait. It also depends on internet speed and processor speed.
  2. Wait till total window handles become two.

Either we can use inbuilt method waitForNumberOfWindowsToBe() of ExpectedConditions class or we can make our own as below-

Code to wait for specific number of windows-

public void waitForNumberOfWindowsToEqual(final int numberOfWindows)               { //Making a new expected condition   
new WebDriverWait(driver,30){}.until(new ExpectedCondition<Boolean>(){   
                   @Override public Boolean apply(WebDriver driver) {

                              return (driver.getWindowHandles().size() == numberOfWindows);}

                          });

}

If you handle this wait in your code, your code become more robust. This is how you can work on multiple windows in Selenium WebDriver.

Happy Learning 🙂