Selenium - set your framework free
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.
Outline/structure of the Session
- Reflect of speaker’s personal experience of using Selenium for automation across companies, products and programming languages
- Success story of keeping Selenium as a constant when product requirements and supported platforms quickly change
- Outline of skills that are considered important for starting with test automation
- Tips on designing Selenium framework to enable getting started with automation easily
- How to use Selenium as the main tool of your test automation and design
- Paradigms of Selenium framework design to enable newcomers to get started with automation
- How to be adoptable and quickly become productive when your product and platform requirement change
schedule Submitted 2 years ago
People who liked this proposal, also liked:
UI Automation As A Web ServiceDipesh Bhatewara
schedule 1 year agoSold Out!
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
- How do you integrate UI automation seamlessly with different test frameworks/suites?
- How do you test all these requirements (UI, API, Performance etc.) effectively without a lot of redundant or duplicate code?
- 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.