Newcomers to test industry have one major question - what programming language to start with? My answer is that the choice of language is secondary to the test technology you decide to use. I typically recommend starting by reviewing the DOM structure of a webpage and writing a basic Selenium test.

My first experience with Selenium was over 7 years ago, when I used Selenium IDE and Firefox to record and playback a basic test scenario, and was captivated by how easy and natural writing test cases seemed. Then I proceeded to writing a test framework for UI automation with Perl and Selenium. The main design goal of the framework was to enable manual testers at the company to get started with test automation. Selenium IDE was a great resource for everyone to understand what the framework did behind the scenes, and start contributing by writing automated tests. Since that time I have worked in Microsoft and currently at Netflix, where I have been advocating using Selenium for most UI automation goals.

After developing and supporting UI test frameworks for multitude of products, using Perl, C#, Objective C, Java and Node.JS programming languages and across different Operating Systems the only constant I have stayed committed to has been Selenium. Flexibility and adoptability of Selenium empowers testers to use their favorite design paradigm, programming language and environment in creating great test automation frameworks.

 

 
4 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  1. Reflect of speaker’s personal experience of using Selenium for automation across companies, products and programming languages
  2. Success story of keeping Selenium as a constant when product requirements and supported platforms quickly change
  3. Outline of skills that are considered important for starting with test automation
  4. Tips on designing Selenium framework to enable getting started with automation easily

Learning Outcome

  1. How to use Selenium as the main tool of your test automation and design
  2. Paradigms of Selenium framework design to enable newcomers to get started with automation
  3. How to be adoptable and quickly become productive when your product and platform requirement change

Target Audience

Everyone

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Dave Haeffner Test
    By Dave Haeffner Test  ~  1 year ago
    reply Reply

    I like the experience report angle. I think it could be more powerful to front-load your talk with that, and then lead into the distilled take-aways (e.g., necessary skills to do automated with Selenium & tips for designing a framework that's easier to start automation with).

    And I would update the talk type, changing it from "Keynote" to either "Talk" or "Experience Report".

    • Lilit Yenokyan
      By Lilit Yenokyan  ~  1 year ago
      reply Reply

      Thanks for the suggestions. I have updated the submission type to 'talk' and the outline to first reflect on my personal experience and lessons learned, and then going into framework design tips.


  • Dipesh Bhatewara
    Dipesh Bhatewara
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    In modern cloud aeon, customers are delivered with UI and API for most of the Enterprise Products. The QE teams have to test the product for UI and APIs from functional as well as non functional perspective. For these they typically end up writing different test suites.

    There are lot of challenges one faces when automating test suites for these different purposes, like

    1. How do you integrate UI automation seamlessly with different test frameworks/suites?
    2. How do you test all these requirements (UI, API, Performance etc.) effectively without a lot of redundant or duplicate code?
    3. How do you use the best fit language/technology for UI automation and still do not impact the grand test automation strategies?

    There is an interesting solution to conquer these challenges which I have recently implemented in one of my projects. 

    The idea is to segregate tests from the UI Automation OR webdriver code. This code can be exposed as a web service APIs. Such service allows us to write common tests for UI as well as API. Tests written for API testing can be reused for UI testing with very minimal configuration modification like pointing to appropriate web service. These UI Automation APIs can also be called easily from any performance test requiring UI interaction.

    This approach will enable any test suite using any language or technology in your organization to reuse UI automation seamlessly. This will also make lot of things straight and simple for execution and management across the verticals.

     

    We will deep dive into the technical solution for this in this talk.