What are the things that one must consider while learning Selenium Webdriver Automation framework?



  • I am a newbie in Automated scripting using Selenium WebDriver with Java. Also, i have the most basic knowledge of core Java.

    With tons of resources on the web for learning WebDriver, i am a bit overwhelmed on how to learn effectively and go deep into this as i want to become practically good in Selenium in next 1/2 years.

    Should i first learn about creating a Selenium Webdriver - Data driven Framework with all helper classes, utilities like excel reader, screenshots class,HTML reports OR should i dive into the Functional scripting of test scenarios of the AUT.

    Also, i plan to use Maven and TestNG with Selenium.Not sure, how can i use those effectively.

    Kindly refer a link to any material/books which can help me clear my automation skill?

    Thanks!(Feel free to close my question, but it would be great if you can refer me something, so that i can follow your advice immediately, without endless surfing)



  • This is going to be blunt. I don't know a not-blunt way to say this.

    First, learn to code. Working with Selenium, no matter what your toolkit happens to be, is writing code. If you don't understand the code or the principles behind the code, you will be constantly frustrated, and worse, you will irritate your peers with what will seem to experienced coders to be "foolish newbie questions" - that is, the kind of question that a typical junior developer would be able to solve for themselves.

    Once you are able to write, read, and understand moderately complex code, then you can start considering adding Webdriver into the mix.

    At this point, I'd start with the following:

    • Start simple - make your first Webdriver test really simple. One method, which handles all the setup, the test actions, and the assertions. Your goal here is to develop a feel for working with the Webdriver API, to sort out the dependencies you need to make sure your browser driver is somewhere the API can access and your code has the right executable permissions.
    • Refactor as you build - Any time you find yourself rewriting or copy/pasting large chunks of code that's almost the same, that's code you can extract into its own method. Whether it lands in a separate library object or namespace will depend on what you need.
    • YAGNI - resist the temptation to add things "for later". "You Ain't Gunna Need It" - or more likely, when you eventually do need "it", what you originally wrote isn't going to do the job the way you want, because you've improved a lot since then.
    • KISS - Keep It Super Simple. As Michael Durrant has already said, you want to minimize testing through the UI. UI work is complicated and involves a lot of moving parts, which means a lot of ways your tests can fail that aren't bugs in the application in test.

    After that, you can start looking at CI, data-driving your tests, and other more complex scenarios, but your best option is to get the basics as solidly as you can before you try to do anything more complex.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2