A Year of Implementing Ideas From SeConf'14
Selenium Conference 2014 in Bangalore was the first time got a chance to attend this event. During the event got exposed to lots of brilliant ideas and experiences shared in various talks.
In last one year had opportunity to try some of them which resonated within Automation Community of our organisation. As part of this talk would like to share our experiences, which might help participants to get it done right first time.
A. Getting the right test pyramid: The idea of having Unit Tests, Integration Tests and GUI Tests in right proportion makes perfect sense. In this part of talk I would like to take you through our efforts to beef up the Integration Tests. It was a two pronged strategy. First automated backend api tests using BDD and some python modules.
Second added integration tests for frontend modules done using ReactJS using Chai, Mocha, Sinon, React TestUtils, PhantomJS etc.
B. Appium for Mobile Automation: Our test infrastructure didn't have capability to support Mobile Automation. To support the Mobile First approach catching up and requirement of rich user experience on mobile for our service we needed Appium.
In this part of talk will share our experiences enabling existing tests to run on Mobile devices using Appium and with iOS/Android emulators, real devices, SauceLabs.
C. Using third party infrastructure service instead of local grid: Idea of not maintaining the test infrastructure and growing number of tests on web and mobile made us look in this direction. We chose SauceLabs as the preferred infrastructure service. This part of talk will cover how we went about trying SauceLabs, challenges we have faced and some pros and cons of using SauceLabs.
Outline/structure of the Session
- Getting the Right Test Pyramid: Adding Integration Tests for backend and frontend.
- API Tests for testing backend model and controller part using BDD in Python.
- Integration Tests for React based frontend components using Mocha, Chai, Sinon, React TestUtils and PhantomJS.
- Appium for Mobile Automation
- Adding support for Appium in existing framework.
- Experiences with iOS/Android emulators.
- SauceLab for running Mobile Tests.
- Using Third Party Infrastructure Service (SauceLabs) instead of local Grid
- Our reasons to try it out, what worked and where we got stuck.
- Exposing local environments to SauceLabs infrastructure and tips to speed up test execution.
Adding backend and frontend integration tests.
SauceLabs usage and benefits.
Test Engineer, Test Lead, QAE, Test Manager, SDET
schedule Submitted 1 year ago
People who liked this proposal, also liked:
schedule 1 year agoSold Out!
Extending Selenium Element Locator Strategies – Element Filteringvishnu nallani chekravarthula
schedule 1 year agoSold Out!
Element Locator strategies for Selenium WebDriver are highly flexible, and have been later inherited by many commercial tools. Although the locator strategies are flexible, they are also limited in a sense that, Selenium WebDriver does not currently allow its users to identify/filter UI elements with multiple locator strategies(at a time), as many commercial tools do.
The solution discussed in this article describes a library that allows Selenium WebDriver users to extend the Selenium element locator strategies for Element Filtering and few use cases for the library.
The solution approach allows users to continue to use the existing UI Element definitions in their tests, and extend them, using the By reference. The library will replace the existing Selenium WebDriver “By” reference.
Filtering based on multiple locator strategies
There are various scenarios where to uniquely identify an UI element, a complex XPath has to be written. However, the element can be identified uniquely using multiple locator strategies for the UI Element. The UI Elements can also be filtered, when there are multiple matches in a page. This is the UI Element recognition mechanism used in many commercial test automation tools.
The algorithm for filtering UI Elements based on multiple locator strategies is based on priority of locator strategies. The priority of locator strategies when filtering is:
- LinkText and PartialLinkText
The By.elementFilter method takes multiple locator strategies, and searches the page for elements matching a particular locator strategy/property, and checks if it is a unique match on the page, if not then it uses the next locator strategy passed to it and so on.
This method is also very helpful when the application undergoes constant changes and UI Elements might have either of XPATH, ID , NAME, TagName, ClassName etc still unchanged. That way, it helps reduce a lot of maintenance effort in Selenium WebDriver implementations which is due to UI element changes.
Filtering based on Index
When there are multiple similar UI Elements in a page, such as cells in a grid/table, it makes sense to identify objects based on their Index based on their appearance on the web page.
The By.indexFilter method allows users to define an UI Element based on its Index of occurrence of the UI Element. The Index starts from 1.
Filtering based on relative element
When a UI element cannot be identified uniquely and reliably by any of its properties, but has some elements in its hierarchy or relative to a particular element, this method can be used to identify the element
The By.relationFilter method allows users to define an UI Element in relation to another element. The relation can be defined as “Left”, ”Right”, ”Top”, ”Bottom”, ”Child”, ”Parent”
Filtering for Tables
When dealing specifically with Tables, which have the
html tag, the By.tableFilter method allows the user to quickly identify specific cells in the table, without having to write complex XPaths or logics to achieve the same.
The By.tableFilter method allows users to define a cell in the table with Row,Column numbers. This allows users to directly use the UI Element in their code instead of writing their logic each time. This also increases efficiency and readability of the code.
Using genetic algorithm to do exploratory testing with cucumber and selenium.Herman Ching
schedule 2 years agoSold Out!
Writing selenium tests has an inherent problem in which we can only automate what we know the steps for. It is primarily used for regression and can scale very quickly. We generally optimize regression for sprint's relevant features or have smoke tests to get quicker feedback. In addition negative testing is very expensive to write. This entire process is very manual and the maintenance of tests become more costly than the actual writing of tests.
We can change this. By using genetic algorithm and cucumber steps we can create new feature files to discover where in the application may be be problematic. The goal of each individual would be to find the most defect. The two individuals that find the most defects then create children that follows the sequences of how new individuals are form through genetic algorithms. They will breed the next generation of testers which will focus on problematic areas.
Let's find out when and if this strategy can be deemed effectively.
Dependency Injection in the Page Object ModelAnthony Browness
schedule 2 years agoSold Out!
The Page Object Model is awesome, but you can make it even better with Dependency Injection. I'll show you how to get started and some benefits of using Spring IOC in your Page Objects. Though the concepts of this talk can be extended to any language, the examples will be shown in Java.