Dedicated to each testers around the world - Happy Tester's Day !!!

Do you have any Idea on the importance of September 9 in a software tester’s life? Well, we will stop using our common term “bug” or “debug” and speak about the influential woman associated with this date.

Every day is Tester's Day for sure, but it's nice to have a day of our own, a special day that can bring all the testers around the world to share, collaborate and feel proud to be one.

Well! September 9 is celebrated as the World Tester's day.

The History

It was on September 9, 1947, that an American computer scientist and United States Navy Rear admiral Grace Murray Hopper noticed the first ever computer bug while working on the Harvard Mark II computer. Soon she traced a moth stuck between a relay in the machine. The first actual case of a “bug” was thus discovered.

The work they performed required some description, and the word had been found – «debugging» (literally: disposal of an insect) – and now it is used to describe the process of identifying and eliminating bugs which cause a computer to malfunction. The removed insect was pasted into the computer log with the entry: “First actual case of bug being found”, and was then transferred to the computer museum.


Since then, the process of identifying and removing bugs from computers was called testing. Subsequently “The Tester” – a completely new profession arose to meet this task.

Now a day's that has grown to a pretty big profession. Now there are Test Analysts, Test Engineers, Quality Analysts, Integration Test Engineers, Software Testers, Systems Integration Testers, Quality Assurance Analysts, Technical Test Specialists…and so on. The interesting fact is that all these designations have risen from a single BUG!

As every one knows, now software testers play with bugs and ensure that the computer software is flawless and of a high quality. Developers may view them as enemies but in reality, they have to thank testers for finding the bugs!! and making them appreciable for releasing a quality product at the end.

Testers don’t break software, software is already broken :)

Testers play a crucial role indirectly in website development by finding the bugs and making sure that everything is in proper working condition.

Hey guys and gals who are into Testing, Today is our day! Come let's celebrate !!!

Let this be our slogan, We do #lovetesting :)

Selenium 3 is finally released - First impressions of Selenium WebDriver 3.0.0 beta 1

And now it's official. Selenium has released it's beta version of Selenium 3.0. 

 Let's go through some of the highlights of the Selenium road-map, which will enable the companies to find plenty of time to figure out what changes to implement in their test suites.

What are the changes going to be between Selenium 2.0 and Selenium 3.0?

One of the biggest change is that the old Selenium Core libraries will be dropped in 3.0. The focus will shift completely to the WebDriver API. 

For the last six years it has been advised to switch to the newer WebDriver APIs and to stop using the original RC APIs. With Selenium 3.0, the original implementation of RC has been removed, replaced by one that sits on top of WebDriver. For many users, this change will go completely unnoticed, as they’re no longer using the RC APIs.

How significant is the removal of Selenium Core?

Most users are already writing tests with WebDriver, so this change won't really impact those users. But for the users of Selenium Core, there may be some significant work ahead if they want to migrate to the future, supported versions of Selenium. They'll need to migrate their tests to WebDriver, but there are ways to preserve your existing investment in tests even if they're older Selenium Remote Control (Selenium RC) tests.

What is the background and status for the W3C WebDriver specification? What is the advantage of having a specification?

The WebDriver API has grown to be relevant outside of Selenium. It is used in multiple tools for automation. For example, it's used heavily in mobile testing through tools such as Appium and iOS Driver. The W3C standard will encourage compatibility across different software implementations of the WebDriver API.

There is a working draft available currently, and the working group hopes to have it finished by the end of the year.

After that first specification is complete and in the browser vendors' hands, work will start on W3C WebDriver Level 2, which will focus on testing standard web user notifications such as allowing geolocation or other, deeper level access through the browser, and access to the shadow DOM.

What are the important Changes?

* Minimum java version is now 8+

* The original RC APIs are only available via the leg-rc package.

* To run exported IDE tests, ensure that the leg-rc package is on the
  classpath.

* Support for Firefox is via Mozilla's geckodriver. You may download
  this from https://github.com/mozilla/geckodriver/releases

* Support for Safari is provided on macOS (Sierra or later) via
  Apple's own safaridriver.

* Support for Edge is provided by MS:
  https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/

* Official support for IE requires version 9 or above. Earlier
  versions may work, but are no longer supported as MS has
  end-of-lifed them.

* New html-table runner backed by WebDriver.

* Unused command line arguments are now no longer parsed.

* maven packaging fixes

* Update GeckoDriver --port argument in all bindings

* System property webdriver.firefox.marionette now forces the server in marionette 

  or legacy firefox driver mode, ignoring any related Desired Capability.

* Grid fix NPE's on registration when -browser not specified.

 What are the changes to be done in using firefox driver ?
If you are using Selenium 3 then to work with Firefox browser you need to use separate a driver which will interact with Firefox browser. If you have noticed then we have done the same thing for Chrome and IE browser as well. One important thing in this post is even if you are using Firefox beta version then it will work. If you are using firefox 47 and so on then it will work.

Let us see how to use the Firefox Marionette Driver

Let’s run a basic program with Selenium 3 beta version

Program 1 without any driver

Output console

The path to the driver executable must be set by the webdriver.gecko.driver system property;

As you can see to work with Firefox we have to set the property now.  You can download the driver from Github and then you can extract and you will get .exe file.

Download URL – https://github.com/mozilla/geckodriver/releases/tag/v0.9.0

 Complete program for Firefox in Selenium using geckodriver

Now you can run the program and you will get expected output.

Firefox Marionette Driver, how to use the Firefox Marionette Driver, selenium, selenium 3, selenium webdriver

How to find Xpaths using WebDriver Element Locator

Finding/Writing XPath is one of the greatest challenge that most of the automation testers come across. In this post I am going to introduce a new plugin before you which will help you in finding the right XPaths just by a click.

This plugin generates different xpaths using xpath finding techniques. With the help of this you can easily generate xpaths for C#, Java, Python, Ruby.

For downloading this plugin for Firefox > Navigate to below url:
https://addons.mozilla.org/en-us/firefox/addon/element-locator-for-webdriv/
[Update/ This plugin is deprecated and hence I reccomend to use the below one]

Firefox : https://addons.mozilla.org/en-US/firefox/addon/truepath/

Chrome: https://chrome.google.com/webstore/detail/truepath/mgjhkhhbkkldiihlajcnlfchfcmhipmn 


Once installed, you can navigate to any element and right click on that element which will generate xpath for that particular element. In the below image we have managed to find XPaths for the donate button.

For the new one it looks like this:

Now I am sure that you have got much relief for the question:

How to find XPaths in Selenium :) 

Happy Testing !

Must Know Visual Studio Keyboard Shortcuts

In this post let me give you a short list of keyboard shortcuts for things you probably do often in Visual Studio. Many of them might be using these but still there are some who are not much familiar with using keyboard short cuts while programming.

Visual Studio Keyboard Shortcuts

Editor Related Keyboard Shortcuts

• Ctrl + Enter   =   Insert blank line above the current line.
• Ctrl + Shift + Enter   =   Insert blank line below the current line.
• Ctrl + Space   =   Autocomplete using IntelliSense.
• Alt +Shift +arrow keys(←,↑,↓,→)   =  Select custom part of the code.
• Ctrl + }   =   Match curly braces, brackets.
• Ctrl + Shift + }   =   Select text between matched braces, brackets.
• Ctrl + Shift + S   =   Saves all files and projects.
• Ctrl + K, Ctrl + C   =   Comments the selected lines.
• Ctrl + K, Ctrl + U   =   Uncomments the selected lines.
• Ctrl + K, Ctrl + D   =   Do proper alignment of all the code.
• Shift + End   =   Select the entire line from start to end.
• Shift + Home   =   Select the entire line from end to start.
• Ctrl + Delete   =   Deletes the word to the right of the cursor.

Debugging Related Keyboard Shortcuts

• Ctrl + Alt + P   =   Attach to process.
• F10   =   Debug step over.
• F5   =   Start debugging.
• Shift + F5   =   Stop debugging.
• Ctrl + Alt + Q   =   Add quick watch.
• F9   =   Set or remove a breakpoint.

Search Related Keyboard Shortcuts

• Ctrl + K Ctrl + K   =   Bookmark the current line.
• Ctrl + K Ctrl + N   =   Navigates to next bookmark.
• Ctrl + .   =   If you type in a class name like Collection<string> and do not have the proper namespace import then this shortcut combination will automatically insert the import.
• Ctrl + Shift + F   =   Find in Files.
• Shift + F12   =   Find all references.
• Ctrl + F   =   Displays the Find Dialog.
• Ctrl + H   =   Displays the Replace Dialog.
• Ctrl + G   =   Jumps to the line number or go to the line.
• Ctrl + Shift + F   =   Find the references of the selected item in the entire solution.

Navigation Related Keyboard Shortcuts

• Ctrl + Up/Down   =   Scrolls the window without moving the cursor.
• Ctrl + –   =   Take cursor to its previous location.
• Ctrl + +   =   Take cursor to its next location.
• F12   =   Go to definition.

Project Related Keyboard Shortcuts

• Ctrl + Shift + B   =   Build your project.
• Ctrl + Alt + L   =   Shows Solution Explorer.
• Shift + Alt + C   =   Add new class.
• Shift + Alt + A   =   Add new item to project.

You can go through the complete list of shortcuts here

How to find all links on a web page using selenium webdriver C#

Sometimes we may need to find some tricky actions on software web applications. Selenium webdriver do not have any direct method to perform any such tricky actions. So we may need to use some tricks in our webdriver test script to enable us to perform some actions on the required web applications. Today let's discuss about how to find all links on a page using selenium webdriver C#

You can use the following method to find all links on a page using selenium webdriver C#

Below is the code which finds all the links on a webpage. We are navigating to a link using Firefox. Next we get all "A" tags using FindElements and iterating through those using ForEach loop.

Importance of Feasibility Study before starting to automate your application

Let's list out a few common questions that every software testers in the automation field might have heard in their career.

1. What to Automate ?
2. Why to Automate?
3. Is this really useful?
4. Are we really in the needs for the Automation?
5. Will you ensure 100% coverage by automation ?
6. When will you finish automating the entire application ?
7. Technology?
8. Manual Intervention? 

& Many more questions ...

If I will give my perspective as a normal user or a person who needs to give his node to say, YES please move on. I will surely ask these questions and as a person who is presenting his idea and standing in front of group of people to convince them for YES. I usually thought why they all are asking this which is again a normal behavior.

We all use lifts in our daily life. You may know that the usage of lifts in our life again an automation which makes us so much use to it, that now we forget about taking stairs. So, we can say ROI matters a lot and the effects of Automation also.

If I will take above as examples, surely they have done lots of analysis and research before putting the real time implementation of Juicer & Lifts in actual. This says that how much important to have analysis and feasibility at initial stage only in order to be able to have good return on Automation's.

The most important thing that you should know is that Automation is always a Team task and a single person cannot accomplish it alone. We cannot say to automation as a sub part of any project. Automation is also a kind of whole project which requires initiation, planning, monitoring, execution, reviews and control.

Let’s move on to major factors before initiating any Automation.

Current state of tasks or needs to be automated: - It is always good to have thorough research on current activity which we are doing manually and how much is the effort we are putting in as well as what is the frequency of doing the same may be in a year or in a month it depends. This analysis will ensure us about the current efforts in numbers as well as what can be the objective for automation.

Feasibility: - There should be an objective if there is any need of Automation somewhere. During analysis sticking with the Objective that what to automate is very much needed as sometimes what happened like for example if we are analyzing the Automation for any recurrent task can lead to automate the process in sub parts. So, if it is the case then have small objectives analyze it in parts and consolidate it to see, what the benefits of the same are globally now.

Benefits of documentation during feasibility study: - Ink is always better than memory. Document or write somewhere that where exactly we need to put more focus, may be any of the objects on the Web Page, may be on any of the functionality of the application, may be complex SQL queries usage, application delays, back-end services etc. This is the first step which makes us more confident that yes we can handle the tough scenarios and here after documenting them and manual analysis, it is good to prepare small automation scripts.

POC through small scripts: - It is always good to do POC for all the documented complex scenario’s in order to able to check run-time difficulties as well as how application will respond to automation and to defining the work flow of automation suite. This will make us more confident towards technology to be used as well as that we already prepared for the coming difficulties as the result of this will lead be the inputs for further analysis as well as taking care of technology needs for the automation. Sometimes, what happens that during this phase, we need switch on to different tool or framework to see which tool or framework goes according to our requirements. Also we can ensure the coverage of the flow that we created and by getting it reviewed from client, we can finalize all the needed functionalities has been covered as per the clients need.

Technology needs: - One of the most important aspect as this derives the future team for the automation as well as the skill set we need to accomplish the task. Documenting all these needs will provide us the knowledge that how much cost we are saving using open source and or if we need total licensed tools that what all can be the yearly savings using this automation if we are spending on tools also. Usually this is also one of the question arises now a day’s what you are using, any training needs, any tool purchase. All of the above questions will become negligible if we initially take care that we should go with current knowledge as well open source tools or frameworks of the team. Why this happens because it is not necessary that you are building automation for a customer only sometimes we automate for ourselves and if it is the case for the customer. We can say, Sir there will be no extra cost on tools and technology because we already have skills required, we have tools n framework and no extra cost is needed. Surely, customer feels more confident towards solution.

Till this half analytical part, we completed thorough analysis; we checked the feasibility of automation for complex tasks as well as we know that what technology we will be using now.

Manual Intervention: - One of the most integral parts of feasibility study is the left manual intervention time during running the automation. Sometimes, what happened we take this into consideration after completing automation and then we realized that we have to put this much of manual effort also to run the same like in preparing inputs, environment preparation, results analysis etc?  It is very much important to document this manual intervention and with steps to be followed for the same because may be while analyzing this manual effort; we can come up to introduce a small macro or small script which prepares our inputs etc.

Workflow: - It is good to come on common understanding regarding the workflow of the activity after automation and manual intervention. This will make other people to understand your thought process that what actually we are trying to do and how it looks like after completion as well this will makes us more confident towards solution.

Maintenance & Risk: - Usually, while analyzing the needs we concentrate on present and forgot about the future challenges or updates needed to have consistent returns from automation in future also. So, it will be good to take care that how much effort we need in future for the maintenance as well as what will be the time period to use the automation. If there is a future maintenance or changes are there in the near future then surely we need engagement of Team also. This shows that it does not matter how excellent the idea is what matters is this really gives us returns in future. Sometimes, we know for the critical and complex technical tasks we need automation and in these cases we usually go with the complexity in order to be able to maintain the quality of deliverables.

Quality: - While analyzing the automation needs, we need to concentrate on Quality of the solution also and how we will go to validate and verify the outputs of the automation suite for the deliverables. This will give us the idea that how to make suitable reporting templates which will be easily analyzed by the client and what all we need to put into those reports.

Estimations: - After analyzing all the aspects for automation, we can move ahead for the exact development costs for this automation. My experience say’s it is good to use Work break down structure here as it will be very easy for anyone to have answers during proposal presentation with Management or with Client. WBS can be next topic to write may be……

The high priority heads, we have covered are:-

•     Current state of task
•     Feasibility
•     Benefits of documentation
•     POC through small scripts
•     Technology needs
•     Manual intervention
•     Workflow
•     Maintenance & Risk
•     Quality & Reporting
•     Estimations

Now, is the time for coming on to the conclusion:-

Return on Investment:- We know what is the objective of the automation proposal, we have the documentation of all the identifications and needs, we have the practical run time examples that where we can stuck and what all can be the technology used or complex tasks solutions can be, how much manual intervention is needed, new workflow, Futuristic risks and new needs, and at last how we are securing are Quality and Customer expectations and reporting. If we consolidate all of the above points and estimations in numbers, we can easily calculate the ROI and can judge from our self only that are we on the right path to automate the objective or it is good to do partial automation or may be no automation is needed.

Highlights:-

• For successful execution of above cycle, we need team as it is good to have opinions and thoughts.
• The conclusion of above points will lead to small presentation preparation in order to be able to put our solution in front of Business.
• The whole above exercise will take time surely but at last the conclusion is really fruitful for everyone.
• By doing this we can easily say that there can be in between changes while developing the solution but not the major ones.
• We know what we are producing and what our responsibility is.
• These exercises gives us more experience and desire to do more towards the same and while analyzing any automation needs, sometimes we come up with our next lead to automates.
• This exercise will give grow team experience towards technology as well as will grow analytical skills.
• One perfect solution and implementation will surely lead to many more like this and with passion.

At last, Automation does not mean Test Automation or Regression Automation. Automation can be possible in any of the scenario, it is just we should be studied well our objective and implementation of Feasibility Study for the same.

Cheat Sheet for Selenium Webdriver

We know there are plenty of cheat sheets for various languages, libraries etc.  I am sure this cheat sheet is gonna help the one's who have started learning Selenium.

This sheet for selenium web driver provides all the important and commonly used methods, operations and commands for your easy daily access.

Selenium WebDriver Cheat Sheet

I hope this list gives you an idea on the basics of Selenium. This post was actually found in axatrikx.

By the way, did I miss something? I would love to hear from you.
Happy Testing, as usual. :)

How to verify if a checkbox is checked using Selenium Webdriver

It's quite a common scenario that we may come across where we need to verify if a particular check box is checked. If not checked we may want to mark it as checked. In this post let's see 

how to check if a checkbox is selected in Selenium WebDriver with C#

First of all make the check-box as a web-element.

Or using findElements code You could instead do as shown below,

What do you think on above selenium topic. Please provide your inputs and comments. You can write to me at meanurajsl@gmail.com.

Challenges and Benefits of Adapting to Agile Methodology

It's always a nightmare when we usually think about getting and setting a team to work together. A team comprises of resources with different attitudes, personalities and roles, working in a similar environment and that is the reason you are in need of some guidelines  and processes in place to keep thing always good and move forward. But trust me, in the long run still you will come across so many challenges. 

Agile Is Fast, Flexible and Iterative.

Today, “agile” is a common usage /practice in many of the software companies. As we all know it's main purpose is to solve many of the problems software teams encounter using the traditional waterfall methodology. In contrast to waterfall, agile is an iterative, responsive approach to building software. It is meant to provide more freedom for the designers and developers as they work on individual modules.

In agile, usually the teams work in sprints (may be short or long), instead of implementing the whole software applications from scratch to finish. The duration of a sprint varies from 1-2 weeks based on the requirements. The main advantage is that, by using an approach like this, both the software testing and customer feedback happen simultaneously rather than waiting for the completion of entire software for attaining these things. 

Waterfall to Agile - What made the transition ?

As we all know, every project or products is entirely different in the world of software development. There is a traditional approach of sequential process  followed by the software teams which was called “Waterfall”.

But in the past several years most of the companies have moved away from the waterfall model. There are a number of reasons for this shift. Mainly this approach was not flexible enough for the fast paces ever changing world of software.

With this approach you will define all the requirements up front and chances are there you stuck with them for the duration of the project. That means, literally you could be building something that was conceived several months before and it may not even be relevant anymore in the current context.

This linear approach has always restricted the software teams and the products they were building. But still, waterfall remained the norm for many decades.

Challenges in adopting agile methodology and how to overcome them. 

 I would say Agile is always a new way of thinking, managing and working. But it's a fact that just like any shift or change in process, many teams have struggled to adopt agile.

However, like any change or shift in process, many teams have struggled to adopt agile. It requires a new way of thinking, managing, and working. Here are some of the common challenges in adopting agile methodology and how to overcome them.

Challenge #1: Getting your client on-board with agile.

For many of the clients, Agile is quite an unfamiliar way of working together which could eventually be really uncomfortable. As in the case of software teams, Clients/Customers are also resistant to change. But there are ways you can overcome this fear of adopting agile though.

Solution: Build trust.

It’s really important to build trust from the beginning, and continue building it after each sprint. By engaging the customer the right way, you’ll build that trust and they will become more comfortable and excited about working with you in this capacity. Worst case scenario is they don’t get comfirtable with agile and you continue to practice agile internally, while bringing in the traditional project or account manager to take on the role of product owner.

Challenge #2: Agile is a cultural shift.

Agile methodology requires your organization to encompass certain values and beliefs. It always require a lot of trust from management side that your team can not only do the work required, but also do it in the best way possible. Your team needs to believe in providing value to both the customer and the product, and you need to empower your team to be creative, make decisions, and work together. Conversely, your team needs to be independent and there by should be able to do these things – make decisions, work well together, and think outside the box.

Solution: Hire an agile coach.

If you’re new to agile or finding that your team is struggling with the shift, it might be worth bringing in an experienced agile coach to avoid some of the issues. If that’s not an option for whatever reason, empower your team to get out in the community and learn from other agile experts.

Challenge #3: Many people think agile should be done exactly a certain way.

It’s often thought that in order to be agile, you need to follow every rule and guideline as instructed. Sure there are a lot of ideas, techniques and practices that go into “agile”, but the perception that there is only one way to be agile is not correct. In fact, it’s far from the truth.

As Anjuan Simmons says,

“Agile is not a one-sized-fits-all methodology that works for every situation. It is a framework that is meant to be flexible.”

Solution: Try different approaches.

In agile itself there are many approaches. Select the one that suits you and go for it. Scrum is by the most popular. But others are also fairly popular today. Search and find these approaches and see which one suits your team the most. Once you settle on one, feel free to change it so that it works with you and your team. It’s ok to only implement some of the techniques.

For example, Maybe one week sprints are too short…try two weeks, or four weeks…whatever works for you team. Likewise, if work break down structure or planning poker isn’t working for estimation, try a different estimation technique.  If daily stand-ups are getting stale and lacking value, move to every other day. Try new things until you find what works for you.

In Conclusion

In short agile enables us to move quickly and easily. Lots of advantages are there to working this way, but it can be a big undertaking and a significant shift in the way teams think and work together. Always know that while adopting agile, the more you prepare and the more you experiment with different ideas and techniques, the better off you’ll be. Never ever try to force it on your team – find what works for you, your team, your customers, and I would say for sure, With this new way of thinking, managing and working, you’ll be on your way to a fast, flexible way of working.



I hope, you might have found these tips to avoid challenges in adopting agile methodology useful. Please lemme know your views and comments .

20+ Must have tools for any Software Tester to make their job easier

I’ve been working as a tester for more than 6 six years. During this period quite a lot has changed in the common QA practices, and I’ve always tried to keep up with times. As I have quite a decent experience in various types of testing, from time to time my colleagues ask me of some advice concerning various tools that simplify performing their routine tasks. This finally brought me to the idea of writing this blog post.

So, I’ve decided to make a list of 20+ Must have tools for any Software Tester to make their job easier.  

Spread Sheet: The most important tool which could be used for Test planning, test case writing, Test analysis etc.

FreeMind - A brain storming tool which have better features for a detailed ideaation.

Jing /  Fastone Capture / Drop.lr  - Capture, Edit and upload Screenshots.

Screencast-o-matic -  This is a screen and webcam recorder, to record on-screen activity for short tutorials, visual presentations, and communicate with complex bugs while you demonstrate!

Measure It - A mozilla/chrome addon which could be used for the verification of pixel perfect designs. 

Texter - Writing test cases or defects , Text substitution app Texter saves you countless keystrokes by replacing abbreviations with commonly used phrases you define

Bubbl - Mind mapping tool , great for brainstorming / idea / sharing information

EtherPad / typewith.me - is an online document collaboration tool which works in real time. In other words, EtherPad has allowed multiple people to work on the same document at the same time over the Internet.

Log-Watch - creates a log file as it goes, reporting strange events and possibly errors that might not appear through the UI

PerlClip - This will generate text , text count and more

Rapid Reporter - Can be used for Session based testing / Exploratory testing

Color Cop - returns RGB values

WebWait - check the speed of your web application

Firebug - Xpaths and JavaScript errors!

Pingdom - Test your page load speeds The Full Page Test gives you a detailed visual report on the load time of each element (images, CSS, JavaScripts, RSS, Flash and frames/iframes). Objects included in javascript are ignored

GTMetrix:  GTmetrix gives you insight on how well your site loads and provides actionable recommendations on how to optimize it.

METS - Minimal Essential Test Strategy (METS) - These are Excel spreadsheets but help in planning and estimating tests.

Beyond Compare - Comparison tool

Sikuli - Sikuli is a visual technology to automate and test graphical user interfaces (GUI) using images (screenshots)

Paloma Print Perfect - STREAMDiff - Comparison of PDF docs

IcuTest - GUI Unit Testing for WPF - http://www.nxs-7.com/icu

LucidChart which is another Visio alternative which is web-based. It has real-time collaboration so lots of people can work simultaneously.

Dia (Visio alternative, helpful for drawing process flow diagrams, etc for test planning) - http://live.gnome.org/Dia

Test Data Generation - This is a really cool web script that you can use for free and even download the script for use on your own server.

Selenium IDE: We can use this tool to generate locators of web elements quickly and easily. This powerful Firefox extension is really helpful in test automation. You can use this tool also for finding and testing already generated locators, which you use in your automated tests, for checking XPath existence on the page, testing the work of Selenium methods with them.

Xenu’s link Sleuth: This is a great tool for checking links. It was named the fastest link-checking software by industry authorities. Apart from checking for broken links, the tool provides a much broader functionality, which is useful primarily for website optimization.

Feel free to add more tools that make your testing Smarter!

How to download PDF files automatically in Firefox using Selenium WebDriver

Here I am trying to explain you, how to download PDF files automatically in Firefox using Selenium WebDriver.

I always believe that learning through examples are the right and easiest way and hence let's see a  complete example of how to save PDF files automatically in Firefox using Selenium WebDriver.

1:  # Environment Tested:  
2:  # Windows 7, Ruby 2.0.0p451, Selenium 2.41.0, Firefox 29.0.1  
3:  require 'selenium-webdriver'  
4:  profile = Selenium::WebDriver::Firefox::Profile.new  
5:  profile["browser.download.folderList"] = 2  
6:  profile["browser.download.dir"] = 'C:\\'  
7:  profile["browser.helperApps.neverAsk.saveToDisk"] = 'application/pdf'  
8:  # disable Firefox's built-in PDF viewer  
9:  profile["pdfjs.disabled"] = true  
10:  # disable Adobe Acrobat PDF preview plugin  
11:  profile["plugin.scan.plid.all"] = false  
12:  profile["plugin.scan.Acrobat"] = "99.0"  
13:  driver = Selenium::WebDriver.for :firefox, :profile => profile  
14:  driver.get('http://static.mozilla.com/moco/en-US/pdf/mozilla_privacypolicy.pdf')  

A walk-through

Prevent Firefox from popping up "Save file" dialog

You may know that Selenium itself doesn't interact with system-level dialogs, in order to download PDFs as part of the browser automation process, it requires the help from either additional 3rd party frameworks or a better approach that could handle the downloading automatically.

Firefox's download manager preferences are controlled by some properties defined in about:config page, which can be set programmatically while instantiating FirefoxDriver using Selenium WebDriver.

• browser.download.folderList controls the default folder to download a file to. 0 indicates the Desktop; 1 indicates the systems default downloads location; 2 indicates a custom folder.
• browser.download.dir holds the custom destination folder for downloading. It is activated if browser.download.folderList has been set to 2.
• browser.helperApps.neverAsk.saveToDisk stores a comma-separated list of MIME types to save to disk without asking what to use to open the file.

1:  profile = Selenium::WebDriver::Firefox::Profile.new  
2:  profile["browser.download.folderList"] = 2 # use the custom folder defined in "browser.download.dir" below  
3:  profile["browser.download.dir"] = 'C:\\'  
4:  profile["browser.helperApps.neverAsk.saveToDisk"] = 'application/pdf'  

It is worth noting that the MIME type defined here is application/pdf, which is a type that most PDF files use. However, if the target PDF file has a non-standard MIME type, then "Save file" dialog might still show up. In order to fix this issue, the actual MIME type has to be added into browser.helperApps.neverAsk.saveToDisk property, which can be checked out using either of the following approaches:

• Upload file to online tools like What MIME?
• Download file and monitor MIME type in Chrome's developer tool or web debugging proxy like Fiddler, Charles, etc.

Prevent Firefox from previewing PDFs

For built-in PDF.js viewer

With the release of Firefox 19.0, PDF.js has been integrated into Firefox to provide built-in ability of displaying PDF files inside browser. It tries to parse and render PDFs into HTML5, which can be automated using Selenium WebDriver in theory. However, to download PDFs instead of preview in Firefox, another about:config entry needs to be changed to disable PDF.js.

1:  profile["pdfjs.disabled"] = true  

For third party PDF viewers

Except for Firefox's built-in PDF viewer, there might be other third party plugins preventing Firefox from downloading PDFs automatically. If a machine has Adobe Reader installed, then default PDF viewing setting in Firefox might have been set to Adobe Acrobat without notice.
To avoid previewing PDFs with those plugins, two more about:config entries need to be configured when starting WebDriver instance.

• plugin.scan.plid.all needs to be false, so that Firefox won't scan and load plugins.
• plugin.scan.Acrobat is a key that holds the minimum allowed version number that Adobe Acrobat is allowed to launch. Setting it to a number larger than currently installed Adobe Acrobat version should do the trick.

1:  profile["plugin.scan.plid.all"] = false  
2:  profile["plugin.scan.Acrobat"] = "99.0"  

5 things to remember while going for Software Test Automation

Usually in testing, there is a saying that: 'if you do something more than once – automate it'. Software testing, where we routinely perform similar actions, is a perfect base for automation. In the modern software development, with the use of continuous deployment approach and microservices, everyone wants to deliver features fast and often. Therefore, test automation becomes even more important, yet still facing some common problems. Based on my experience, here is my list of top 5 things to remember while going for Software Test Automation.

Stability

Always-red ? False Fails? We all know that. Stability of automated tests is one of the most obvious issues, yet most difficult to obtain. Even big players like LinkedIn or Spotify admit to have struggled with it. While designing your automation, you should put extra attention to stability, as it is the most frequent cause of failure and test inefficiency. Writing tests is just a beginning, thus you should always plan some time in sprint for maintenance and revisions.

UI perspective

Majority of modern applications are web-based, therefore the most preferable way for functional testing is from the UI perspective. Despite their usefulness, browser tests also have some substantial problems like slow execution time or stability randomness.  Since we’re in the world of microservices, it’s worth to consider dividing tests into layers – testing your application features directly through webservices integration (or backend in general) and limiting UI tests to a minimal suite of smoke tests would be more efficient.

Overmocking:

Because of many dependencies over the systems, mocking services become a popular pattern and are also often forced over test environment limitations. However, you should pay great attention to the volume of your mocked checks – mocks can miss the truth or be outdated, so your development would be held on false assumptions. There’s a saying: “Don’t mock what you don’t own”, which means you can stub only these pieces of architecture that you’re implementing. This is a proper approach when you test integration with the external system, but what if you want to assume stable dependencies and test only your implementation? Then yes, you mock everything except what-you-own. To sum up, the mocking and stubbing strategy can differ depending on test purposes.

Tight coupling with framework

That’s a tricky one. Developers often tend to choose frameworks and tools based on the current trends. The same applies to test frameworks where we have at least a few great frameworks to use just for a test runner, not to mention the REST client, build tool and so on. While choosing a technology stack, we should bear in mind the necessity to stay as much independent from tools as we can – it’s the test scenario that is the most important, not the frameworks.

Keep it simple

Depending on your team structure, acceptance tests are implemented by developers or testers. Usually the developers are better in writing code, while the testers have a more functional approach (it’s not a rule, though). Automated test are not a product itself, but rather a tool, therefore I would put functionality over complexity. Your test codebase is nearly as big as the tested system? Try to categorize tests according to their domain or type. Adding new tests requires a time-consuming code structure analysis? Sometimes a more verbose (but more readable) code is better for your tests than complex structures.

 Summary

It takes proper planning, realistic expectations and a solid commitment to make test automation work. The worst-case scenario that can happen to your automated tests is abandoning them due to relatively simple, yet common issues. Time saved by automating simple test cases can be used for executing more complex scenarios manually, and that leads to better software quality and higher employee motivation in general.

If you have some other interesting experiences with test automation, please comment below!

Is maintenance of Selenium Scripts - a hell ???

Most times we find ourselves scratching our heads and thinking, 'Why did it fail? It was working perfectly in the local server....'. Timeout or 'Session ID is null or Element not found' (my favorite) errors can be especially annoying when we are currently working on the most famous testing task: make all test pass. Let's analyze together how to fix this unhealthy situation.

First of all we need to redefine our task with management. Why so? Having dummy test methods is definitely not what we want to achieve (and not what managers expect from us). Our real task can be defined as:

Make your tests cover as many functionalities as possible, but avoid false results at ALL COSTS.

I emphasized 'all costs' because I want to make a point which you may find controversial:

Even the most important tests should be excluded from automated suite if they are unstable. After exclusion we need to:

a) prioritize test-fixing task (according to test importance/coverage)
b) perform manual test until automated one isn't stable

Certainly do not run test locally (and do not force programmers to do that...). This approach leads to nowhere.

I know we shouldn't, but what if we depend on other services, DBs, factors?Automated test dependencies should be verified before test execution, and if such one exists test should be ignored.

There is one thing which we often forget about. As a QAs/testers we are responsible for building trust in automated tests throughout team/company. False test results are the single most important factor which reduces (or even destroys) this trust.

Even from the most selfish perspective there is important argument against non-stable tests. Writing/maintaining tests with false results will combine you work image in the eyes of others with word 'FAILURE'. Avoid it at all costs.

10 tips for improving the speed of selenium script execution

As you all know Selenium WebDriver is amazing for test automation. But sometimes automation scripts are slow in general.

What do you do when the scripts are slow?

Do you accept that this is how things are?

Or try to find solutions?

Here are the top 10 tips for improving the speed of  selenium script execution.

Why Are Selenium WebDriver Scripts Slow  ?

We use the Selenium WebDriver framework for automating the functionalities of a web application.

Automation scripts are created using

• a programming language

• a unit testing framework

• the Selenium WebDriver framework

When the automation script is executed, the following happen

• the browser is started on the computer

• the site is loaded in the browser

• the script interacts with the site in the browser

Many factors can impact the script's speed:

• if the computer is not fast, starting the browser is slow

• if the internet connection is not fast, loading the site is slow

• the site can be slow for many reasons (high number of concurrent users, slow servers)

               
10 Tips For Faster Scripts:

#1: Use Few and Fast Locators

When locating an element, start with the fast locators:

1. LOCATE ELEMENT BY ID
This works if the html element has the id attribute.
It is the fastest locator as it uses the optimized document.getElementById() JS command.


2.LOCATE ELEMENT BY NAME
This works if the element has a name attribute.

3. USE A CSS SELECTOR
It is faster than XPATH but not as flexible.

4. USE AN XPATH SELECTOR
This is the most flexible strategy for building locators.
Xpath selectors are slow as the page browser DOM is traversed for finding elements.

It is important that the script uses as few elements as possible, especially if using XPATH locators.

#2 - Use Only Explicit Waits

One of the best ways of making a script faster is by using explicit waits.
If your test scripts uses implicit waits (or delays)s,
WebDriver driver = new FirefoxDriver();
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
driver.get(pageUrl);
WebElement element=driver.findElement(By.id(“myId"));

replace the implicit waits with explicit waits:

WebDriver driver = new FirefoxDriver();
WebDriverWait wait = new WebDriverWait(driver, 10);
driver.get(pageUrl);
WebElement element = wait.until(ExpectedConditions.
presenceOfElementLocated(By.id(“myId")));

The script performance is better with explicit waits.
Elements are accessed as soon as they are available.
No additional waiting times are needed.

#3 - Write Good Atomic Tests

ATOMIC TESTS

Each test should test a single tiny bit of functionality.
It is better to have more small scripts focused on one thing only than fewer big scripts that do too many things.
Each test has up to 20 steps.
Each test runs in under 10 seconds.
Having atomic tests is very useful in case of failures.
If any of the smaller tests fails, it is very clear where the problem is.

GOOD TESTS

Good tests are created by following a few simple rules:
1. Eliminate step duplication
2. Keep the scripts independent
3. Write just enough steps to go quickly from A to B
4. Remove steps that are not related to the final result

Good written tests are fast tests.

#4 - Use The Chrome Driver

If your test automation script needs a real browser but not a specific one,

Use the Chrome browser and the Chrome driver.

The Chrome browser is faster than IE, Firefox, Safari and Opera.
The Chrome browser driver is faster than the IE, Firefox, Safari browser drivers.

#5 - Use Headless Browser Drivers

If you don't need a real browser, headless browsers can make your script faster.
Headless browsers do not have a user interface.

The most popular headless browsers are:
1. HTML UNIT
- headless browser written in Java
- uses the RHINO engine (not used by any real browser)
- provides JS and ajax support, partial rendering capability

Example
driver = new HtmlUnitDriver();



2. PHANTOM JS
- headless browser that uses the WEBKIT layout engine (used in Chrome and Safari) for rendering web pages and Javascript Core for executing scripted tests
- uses Ghost Driver as an implementation of the WebDriver Wire Protocol


The following example shows how to create a Phantom JS Driver object.

Example:
DesiredCapabilities caps = DesiredCapabilities.phantomjs();
caps.setJavascriptEnabled(true);
caps.setCapability(“phantomjs.binary.path",
"c:\\selenium\\browserdrivers\\phantomjs.exe");
caps.setJavascriptEnabled(true);
driver = new PhantomJSDriver(caps);

#6 - Re-use The Browser Instance

A typical JUNIT class includes:

1. setUp() method
2. tearDown() method
3. test scripts

The setUp() method uses the @Before annotation.
It runs before each script to create the driver object and open the browser.
The tearDown() method uses the @After annotation.
It runs after each script to destroy the driver object and close the browser.
Each test script uses its own browser instance:
setUp() –> Test Script 1 --> tearDown()
setUp() –> Test Script 2 --> tearDown()

The browser instance can be shared by all scripts when using different annotations:

1. @BeforeClass for the setUp() method
2. @AfterClass for the tearDown() method

In this case, the setUp() method runs before all test scripts.
The tearDown() method runs after all test scripts.
After each test script, the browser is not closed so the next script can re-use it:
setUp() --> Test Script 1 --> Test Script 2 --> tearDown()

#7 - Run Scripts In Parallel

By default, JUNIT test scripts run sequentially.
There are a few options for running them in parallel:
1. Run the scripts in parallel on the local computer
This is done by creating a Maven project in Eclipse and using the Maven Surefire plugin.
Maven Surefire allows methods or classes to be run in parallel.
It also allows the thread count to be set up.
Using Maven Surefire reduces the execution time with about 50%.

2. Use Selenium Grid
There's two reasons for using Selenium-Grid:
- to run your tests against multiple browsers, multiple versions of browser, on different operating systems.
- to reduce the time it takes for the test suite to complete
Selenium-Grid is used to speed up the execution of a test pass by using multiple machines to run tests in parallel.

3. Use Sauce Labs (selenium grid in the cloud)
It works similar with Selenium Grid,
But you don't need to set up the grid environment.
It has hundreds of combinations of browser/device/operating system available.

#8 - Use HTTP Parse Libraries

There are cases when Selenium WebDriver is not the best option for creating test scripts.
If the test script involves navigating through a lot of pages, using HTML parsing libraries like JSOUP is a better choice than Selenium WebDriver.



JSOUP is a Java library for working with real-world HTML.
It provides a simple API for extracting and manipulating data, using the DOM, CSS, and jquery-like methods.
JSOUP parses HTML to the same DOM as modern browsers do.

• scrape and parse HTML from a URL, file, or string

• find and extract data, using DOM traversal or CSS selectors

• manipulate the HTML elements, attributes, and text

How does a script using JSOUP look like?

@Test public void test1() {
Document resultsUrl = Jsoup.connect(basePageUrl).get();

Elements titles = resultsUrl.select(“span.title");

for (Element title : titles) {

Element link = title.child(0);

String detailsUrl = basePageUrl +link.attr(“href");

Document detailUrl = Jsoup.connect(detailsUrl).get();

Elements bookTitle = detailsUrl.getElementsByAttributeValue(“testid", “text_bibtitle");

if (bookTitle.size() > 0)
assertTrue(bookTitle.get(0).text().length() > 0);

Elements bookAuthor = detailUrl.getElementsByAttributeValue(“testid", “author_search");

if (bookAuthor.size() > 0)
assertTrue(bookAuthor.get(0).text().length() > 0);
}
}
}

#9 - Pre-Populate Cookies

Pre-populating site cookies can speed up scripts by avoiding additional site navigation.

Lets take the following test case:

1. open the home page of a site
2. execute a keyword search
3. the results page is displayed with 10 results; language is english
4. go to page 2 of results
5. change the language to french; the page reloads in french
6. change the number of results to 25; the page reloads with 25 results

For page 2, the script needs to

• change the language through a listbox; the page reloads when a different language is selected.

• change the number of results through another listbox; the page reloads with the new number of results

Since the page sets cookies when the results number and language change, it is easy to add cookies to the site before loading page 2.

This way, page 2 will load directly with 25 results, in french.

Code Sample:
public void addCookie(String name, String value) {

Cookie pageSize = new Cookie.Builder(name, value)
.domain(“vpl.bibliocommons.com")
.expiresOn(new Date(2016, 12, 31))
.isSecure(true)
.path(“/")
.build();

driver.manage().addCookie(pageSize);
}

@Test
public void testResult() throws InterruptedException {

//page opens in english with 10 results
driver.get(“https://vpl.bibliocommons.com/search?q=java&t=keyw...");

addCookie(“page_size", “25");
addCookie(“language", “fr-CA");

//page opens in french with 25 results
driver.get(“https://vpl.bibliocommons.com/search?page=2&q=java...");

}

#10 - Do Not Load Images

Many web pages are rich in images so they load slowly.
If the page loads slowly, the script is slow as well.
A page loads faster if no images are loaded.
Disabling images is done by setting up a new browser profile and disabling images for it in the Settings page.
In the test script, use the new browser profile when starting the browser driver:

1. In chrome type : chrome://version/
2. Using the console, navigate to the Chrome exe directory
3. type : chrome.exe –user-data-dir="your\custom\directory\path" to create your custom profile.
4. When chrome opens and asks for a new account to be created, decline
5. In Chrome, go to
Settings>
Advanced settings>
Privacy >
Content Settings >
Images >
Do Not Show Any Image
6. Close chrome. Reopen it again from the console with the same command sequence used in 3. Verify that it is not loading any images in a site
7. Now, in your code, create the capabilities for the driver using the new profile.
System.setProperty(“webdriver.chrome.driver", “C:\\Selenium\\BrowserDrivers\\chromedriver.exe");
ChromeOptions options = new ChromeOptions();
options.addArguments(“user-data-dir=C:\\Selenium\\ChromeProfile");
options.addArguments(“–start-maximized");
driver = new ChromeDriver(options);

Mobile Testing Challenges for the Software Testers in 2016

1. Native vs Web-view

This has been a continuous problem that will most likely be around for a long time; the willingness to get an API ready and complete and not resorting to having to use web views and other clunky alternatives.

Testing a hybrid app in the sense that some parts are native and some parts are webviews is a particular pain in the butt. When using these two side-by-side you can pretty much always notice that native is faster so a webview will always look slower and buggy. There’s almost always a problem with the API and a webview talking to each other.

Solution: If you’re going to build an app, make sure you have all the APIs you need ready and raring to go before dev starts or early enough that something can be done about it.
If not go for all webviews and keep the app looking consistent in one form or another. At least this way it won’t be noticeably different as you traverse the app.

2. Mobile Test Automation

Mobile test automation isn’t in a great place – the market is dominated by either big player pushing sub-standard, expensive tools to ‘automate all the things’ or smaller open-source tools that are at the mercy of the mobile OS vendors.

Too many people still have an ‘automate all the things’ test strategy for mobile, not realising that doing this is even more fool-hardy than on desktop web. Mobiles are complicated and automating a lot via the app UI is not the best strategy at all.

Solution: Focus on understanding your application and the web services it most likely uses. Automate those first. Apply a small, light-weight automated UI test set using whatever automation tool suits you best. Be aware that the automation tool you use may stop working because an OS vendor cut’s access to APIs so have a plan B.

3. Fragmentation

There are soooo many Android devices out there that you can only test a small fraction of them. Add to that the different flavours of OS’s (Samsung adds something, other manufacturers do so too) and you have many potential risks.

Solution: I’d like it if only stock Android was used but hey…I can keep on dreaming I’m afraid. As far as I know, there’s no simple solution. You just have to engage with your customer and talk about which devices / OS’s must be tested (based on facts like most popular devices in your country etc).

4. Unexpected pop-ups

It’s hard to write a repeatable automation test script when at any given time, an ad or other alert-style window appears and obscures the screen below. This has been a problem since the creation of the GUI and is still a problem in 2016. (Ads are mostly the problem now.)

Solution: Create a routine that is always running in a background thread and scanning the screen for a list of “usual suspect” pop-up windows. And if found, perform the actions necessary to remove it — usually it’s sending an “Escape” key event. You also have to make the main script flexible enough to know to wait if it gets “stuck” by a pop-up.

5. In The Wild Testing

One of the biggest challenges software testers need to handle in 2016 is manual “In the wild testing”. The problem that I see, is that many software testers, test mobile applications in the same way as they would test web or desktop applications, always on the same place with the same Internet connection. But mobile apps are not the same like web or desktop applications. They are used in a total different environment with different Internet connections. If a mobile app is tested only with a fast and stable Internet connection lots of problems will not be covered during the testing and development phase.

Testing the app in the wild may find problems with:

1. The light situation because of sun or rain.
   
2. With the sensors because they are interfered by other elements such as buildings, cars or other obstacles.
   
3. With the Internet connection. Due to the movement, uses have not always the same Internet connection and this has an impact to the mobile app under test. For example, the network switch from LTE to Edge may influence the UI or the information that will be processed between the backend and the mobile app.

The listed points are just some of the problems that will not be found in a lab situation.

Solution: The solution for this problem is pretty easy. Software testers must test outside the office. Depending on the use case of the app, the environment may change. For example if you are testing a business app, the app is likely used when people are commuting to or from work by train or car. Or if you are testing a sports app, that is tracking your workouts and activities, then you must test during this situations, too.

It is key for every software tester to test in the environment where the customers will use the app. I recommend to every software tester, to pack some devices in a backpack and to leave the office to test the app in the wild.

When testing in the wild it is important that the app under test is using a crash reporting tool like HockeyApp or Crashlytics to record any kind of problems that may happen during the test scenarios. Besides that I recommend to have just a pen and a piece of paper with you to make notes when discovering a problem.

Different kind of Exceptions occuring In Selenium WebDriver.

While automation it's quite common that we all come across different kind of Exceptions occurring In Selenium WebDriver.

 Lets see few Exceptions and what’s the reason for those !!!!  I hope this post will help you in memorizing such exceptions which you have been facing.

NoSuchElement : An element could not be located on the page using the given search parameters.


NoSuchFrame : A request to switch to a frame could not be satisfied because the frame could not be found.

StaleElementReference : An element command failed because the referenced element is no longer attached to the DOM.

Firefox Not Connected : Firefox browser upgraded toop new version.

ElementIsNotSelectable : An attempt was made to select an element that cannot be selected.

UnknownCommand : The requested resource could not be found, or a request was received using an HTTP method that is not supported by the mapped resource.

ElementNotVisible : An element command could not be completed because the element is not visible on the page.

InvalidElementState : An element command could not be completed because the element is in an invalid state (e.g. attempting to click a disabled element).

UnknownError : An unknown server-side error occurred while processing the command.

JavaScriptError : An error occurred while executing JavaScript code.

XPathLookupError : An error occurred while searching for an element by XPath.

Timeout : An operation did not complete before its timeout expired.

NoSuchWindow : A request to switch to a different window could not be satisfied because the window could not be found.

InvalidCookieDomain : An illegal attempt was made to set a cookie under a different domain than the current page.

UnableToSetCookie : A request to set a cookie’s value could not be satisfied.

UnexpectedAlertOpen : A modal dialog was open, blocking this operation

NoAlertOpenError : An attempt was made to operate on a modal dialog when one was not open.

ScriptTimeout : A script did not complete before its timeout expired.

InvalidElementCoordinates : The coordinates provided to an interactions operation are invalid.

IMENotAvailable : IME was not available.

IMEEngineActivationFailed : An IME engine could not be started.

InvalidSelector : Argument was an invalid selector (e.g. XPath/CSS).

Hope this post helps you guys…! And Please Correct me if there is something to be added…! ;)

A Detailed Guide on different type of Selenium WebDriver Wait

In automation, waiting is having the automated task execution elapse a certain amount of time before continuing with the next step. Selenium WebDriver provides various commands for implementing wait. In this post, we have listed out all the Selenium WebDriver wait commands for your reference.

Conceptually, Selenium WebDriver wait commands can be divided in various different categories. These are implicit wait, explicit wait, timeout, expected conditions, fluent wait etc. We will go through each one of them with their usage in this post. Whenever possible, we have provided code snippets for clear understanding. Implicit Wait: Implicit wait tells Selenium instance to wait for specified amount of time before throwing an exception. The default setting is 0. Let’s see how implicit wait works. While execution, if WebDriver cannot find element to act upon immediately, it will wait for specified amount of time. During this time, no attempt is made to find an element. After completion of specified time, WebDriver will try to find an element once. Exception is displayed if element is not found after that. Once set, the implicit wait is set for the life of the WebDriver object instance. That means it will be available for the entire time the browser is open.

Implicit wait can be implemented by using below code.

driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);

  
Explicit Wait: As the name suggests, we explicitly instruct WebDriver for waiting by using explicit wait. By using custom coding, we tell Selenium WebDriver to wait for some expected condition. Why use explicit wait when implicit wait is in place and doing good already? Glad you asked. Well, you may encounter instances when some element takes more time to load. Setting implicit wait for such cases doesn’t make sense as browser will wait unnecessarily for the same time for every element, increasing the automation time. Explicit wait helps here by bypassing implicit wait altogether for some specific elements.

Now let’s see how explicit wait works. WebDriver provides WebDriverWait and ExpectedConditions classes to implement explicit wait. Below code shows using WebDriverWait and ExpectedConditions for explicit wait. In this code, WebDriver will wait for 10 seconds before throwing a TimeoutException. If element is found, it will be returned in 0-10 seconds.

1	WebElement someElement = (new WebDriverWait(driver, 10)).until(ExpectedConditions.presenceOfElementLocated(By.id("elemendId")));

WebDriverWait by default calls the ExpectedCondition every 500 milliseconds until it returns successfully. ExpectedConditions class has some predefined common conditions to wait for an element.

Fluent Wait:
Unlike implicit and explicit wait, fluent wait uses two parameters. Timeout value and polling frequency. Let’s say we have timeout value as 30 seconds and polling frequency as 2 seconds. WebDriver will check for element for every 2 seconds until timeout value (30 seconds). After timeout value is exceeded without any result, exception is thrown. Below is a sample code which shows implementation of fluent wait.

1 2 3 4 5 6 7

Wait wait = new FluentWait(driver).withTimeout(30, SECONDS).pollingEvery(2, SECONDS).ignoring(NoSuchElementException.class); WebElement testElement = wait.until(new Function() { public WebElement apply(WebDriver driver) { return driver.findElement(By.id("testId")); } });

Another advantage of using fluent wait is, we can ignore specific types of exceptions (Eg. NoSuchElementExceptions) while waiting. Due to all these provisions, fluent wait is helpful in AJAX applications as well as in scenarios when element load time fluctuates often. Strategic use of fluent wait significantly improves automation efforts.

Timeouts:
Apart from waits mentioned about, Selenium WebDriver provides timeouts. There are two timeouts supported: pageLoadTimeout and setScriptTimeout. Let’s go through each one of them.
pageLoadTimeout: It sets the amount of time to wait for a page load to complete before throwing an error. If the timeout is negative, page loads can be indefinite. Use below code to implement pageLoadTimeout.

1	driver.manage().timeouts().pageLoadTimeout(100, SECONDS);

setScriptTimeout: It sets the amount of time to wait for an asynchronous script to finish execution before throwing an error. If the timeout is negative, then the script will be allowed to run indefinitely. Use below code to implement setScriptTimeout.

1	driver.manage().timeouts().setScriptTimeout(100,SECONDS);

Sleeper:
Using sleeper in your Selenium tests is not a good practice and should be avoided. Reason for this is, it forces browser to wait for specified amount of time. It unnecessarily delays other automation steps. You can implement sleeper in your test with below code.

1	thread.sleep(5000);

Here time value is in milliseconds.

You should always consider context while using Selenium WebDriver wait in your automation activities. Proper usage of waits would make your test robust and efficient. With that we hope our coverage of different Selenium WebDriver wait above will be helpful to you. Let us know your views on this.