This is probably the most straightforward exception that you will come across. The element you are trying to find does not exist. There are three common causes for this exception:

• The locator you are using to find the element is incorrect
• Something has gone wrong and the element has not been rendered
• You tried to find the element before it was rendered

The first one is pretty easy to check. You can use the Google Chrome development tools to test your locator. To do this follow these steps:

1. Open the Chrome development tools (cmd + Alt + I or Ctrl + Alt + I)
2. If your site has multiple frames, or iframes, make sure you select the correct frame
3. Type $(<myCSSLocator>) or $x(<myXPathLocator>) into the console

If the locator finds an element, or multiple elements that match the locator, it will display it in the console. You will then be able to examine the element(s) and reveal them in the markup to check that it is the element you think you are finding.

You don't have to use Google Chrome to do this. Most browsers have their own development console. There are also other tools available to you. If you use Firebug, there is an additional extension called Firepath, which is very useful for this sort of thing as well.

The second one is a little harder to diagnose, as you will need to walk through your code and see what happens to cause the failure. Is it a bug in the application you are testing, or is the previous step failing (that is, did you use valid login credentials)?

Screenshots can be a big help in diagnosing NoSuchElementException issues, as they give a good view of the state of the application you are testing when the error failed. They are, however, not infallible. If the cause of the problem is that the element has not yet been rendered, it is possible that the element was not rendered when the error occurred but it was rendered when the screenshot was taken. In this case, the screenshot will appear to show the element was there, when in actual fact it was missing when Selenium tried to find it. These are normally a little bit awkward to diagnose, but if you watch the test running in a browser, you will normally catch it eventually.

This brings us nicely to the third potential problem. Lots of modern websites use technologies such as jQuery or AngularJS, which use JavaScript to manipulate the DOM. Selenium is fast; in many cases it's ready to start interacting with your website before all of the JavaScript has finished doing its job. When this happens, things may seem to be missing when in reality they just haven't been created yet. There are some tricks that you can use to wait for JavaScript to finish rendering the page, but the real solution is to know the application that you are automating. You should know what is required for the page to be ready to use and write your code to be aware of these conditions. A good question to ask in many situations is: What would I do if I were testing this manually?

Normally, you would wait for the page to load before starting your testing; you have to write your code so that it can do the same thing. Explicit waits are usually your best friend in this scenario. You should never use Thread.sleep() to wait for the page to load. If you do this, you are tailoring the test to work on your machine, and your machine alone. If the test is run on a slower machine, the sleep that you have added will most likely not be long enough and the test will fail. If the test is run on a faster machine, it may work, but it will make the test slower than it needs to be.