Saturday, May 10, 2014

Seriously troubleshooting issues in WebDriver is easy, if you know what you're doing. Knowing what you're doing isn't easy; it requires a lot of learning and practice. I’m going to attempt to outline some basic steps to troubleshoot some common issues people encounter when using WebDriver.

At this point I'm planning to make 4 blogs on troubleshooting, in the first blog I want to make sure everyone understands at a high level of how the major components interact. The rest of the blogs will show common issues and how to troubleshoot the possible causes.

First, you need to understand that web sites and web browsers are built to give the user the illusion of full synchronized applications. What’s really happening? The “Server” is hosting a “Web Site”. The “Server” serves the “web Site” to a “Client”. The “Client” aka “Browser” renders that “Web Site”. The communication between the “Client” and “Server” is over a stateless protocol called HTTP. This will be the cause of much confusion when you're working in UI Automation so a good understanding is required if you want to be proficient. Look if you don't understand this, you should before you move on!

Second, you need to understand the fact that WebDriver is an API that allows you to interact with the browser (remember the browser is just one side of that illusion of synchronization). As you might guess when you develop with an API that interacts with an illusion you're likely to have some issues. A good portion of the time when you have a tough issue it’s related to the connection of the following items:

Developer uses Tests & Code to interact with WebDriver

WebDriver uses native calls interact with Browser

Browser uses HTTP interact with Web Site

I have notice Developers who are learning or lazy can be quick to place blame WebDrivers interaction with the browser. More often than not I find the issues to be the test code or the web site code, but if you find a “real” issue with WebDriver, good on you… File a defect with Selenium WebDriver and give yourself a gold star.

Third, you need to keep learning and experimenting.

Last, you need to be able to model these interactions and concepts in your head when come across real tough problems because troubleshooting tough software issues is more than check 1, 2, 3, done. Troubleshooting tough software issues is problem solving and understanding complicated interactions when they have unexpected results, and that ain't easy. People don't naturally consider all possible outcomes of an action, especially if that outcome is unlikely. So when learning a thing it's good to understand it as a whole and just as it applies to your happy path.

Monday, May 5, 2014

NoSuchElementException seems obvious but it can be a misleading error and people can have a hard time filtering out the actual root cause. The NoSuchElementException means the specific element did not exist at the time the call was made plus the duration of the implicit wait.

There are many reasons this might happen, lets walk over some of the common reasons:There is no web element with an ID of "text1"
What to look for, the element may have been removed or the ID may have been removed or changed.

Element doesn't exist, navigate to the URL and view the source code

Verify that the web element exists

Verify that the ID = “text1”

The element did not load within 10 seconds
What to look for, the element may have been loaded after the 10 seconds

Never loads in less than 10 seconds, navigate to the URL and see how long it takes for the element to appear on the page

Verify that it happens in less than 10 seconds, each time you go to a page the time could be different so doing this multiple times could help provide insight. My general rule is if it should take 4 seconds expect it to take 8 seconds and wait as much as 12 seconds. (Should take X, Expected X*2, Wait X*3)

Intermittently loads in less than 10 seconds, Consider each Runtime Context separately, simple example: It works on my laptop but not on build machine

Verify hardware, how long it takes on each machine: laptop 3 seconds, build machine 12 seconds. If this were true you might expect other operations have the same ratio.

Verify time of day and day of week, what time are the failures. If fails every Saturday 5:00am, what else is happening at that time, DB back up, system updates, virus scans, etc…

The element could be inside an iframe.
What to look for, the element might not be part of the parent html page it may be contained inside of an iframe.

The web element is present but not in the pages DOM

Verify if the web element is a dependent of an iframe

So these were just some of the things that could have caused this error, there are a host of other reasons the NoSuchElementException would be raised. I think the most important thing to remember is be flexible and not get locked into a specific way of thinking. Try to visualize what happened over the wire and in the browser. Sadly I have seen people lose hours and days without trying the steps above thats why I finally decided to blog it out.