location_city Portland, OR schedule Sep 10th 01:30 - 02:15 PM IST place Grand Ballroom 1

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 Experience Report

  • 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.

Learning Outcome

Adding backend and frontend integration tests.

Mobile Automation.

SauceLabs usage and benefits.

Target Audience

Test Engineer, Test Lead, QAE, Test Manager, SDET


schedule Submitted 7 years ago

  • James Eisenhauer

    James Eisenhauer - An Introduction to the World of Node, Javascript & Selenium

    45 Mins

    Ever wanted to write Selenium code in Node.js?  There seems to be a new javascript library written every hour!  Entering the world of Node.js can be a daunting task.  This session will teach you everything you need to know to make the right decisions when selecting what libraries you should implement on your new Node.js Selenium project and what the possible challenges will be.



  • Anthony Browness

    Anthony Browness - Dependency Injection in the Page Object Model

    45 Mins

    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.

  • vishnu nallani chekravarthula

    vishnu nallani chekravarthula - Extending Selenium Element Locator Strategies – Element Filtering

    45 Mins

    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:

    1. ID
    2. Name
    3. TagName
    4. ClassName
    5. XPATH
    6. LinkText and PartialLinkText
    7. CSS

    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.

  • Herman Ching

    Herman Ching - Using genetic algorithm to do exploratory testing with cucumber and selenium.

    Herman Ching
    Herman Ching
    QA Engineer
    schedule 7 years ago
    Sold Out!
    45 Mins
    Experience Report

    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.