"This world is such a beautiful place to live in." If you can read the first sentence without any screen readers or assistance, you're privileged. As technologists, shouldn’t we be more empathetic towards differently-abled people and make all parts of our website accessible to them? In my humble opinion, the true power of technology can be identified when it reaches out to people of all kinds having different physical or psychological challenges. We not only legally bound to provide Accessibility but also it should be considered as our moral responsibility.

As testers, we have a wonderful opportunity to contribute to Accessibility by ensuring that the site is accessible in many different ways. Although it is impossible to identify all the issues that exist around Accessibility in the world, we are lucky enough to still understand a majority of them. With this understanding, there have been many measures taken in order to make your site accessible. But, don’t forget - we are QA engineers. We got to ensure that the site is accessible as per the standards set by WCAG 2.0 (AA) by testing for accessibility using various tools and techniques.

Shadow DOM is kind of web standard that developers use to encapsulate their custom HTML code and style components so that no other global style components can override their code. It ensures that a component will work in any environment, even if other CSS or JavaScript is run on the page i.e. Shadow DOM hides away the complexity of the components from the rest of the page because it renders separately from main DOM.

Selenium legacy selectors are not able to interact these custom elements under the shadow DOM so we need java script to interact with shadow DOM elements and we also require JavascriptExecutor interface for their execution.

We will also talk about the WebdriverIO tool v5.5.0, which implicitly support Shadow DOM elements.

Puppeteer is a Node js library (developed by Google Chrome team) to control Chrome and Firefox and is getting lot of traction recently because of its amazing capabilities. It has already become so popular that it has got 50K+ stars on Github against Selenium's 15K+ stars.

In the last Google I/O event, this tool's capability has been showcased and it has been perceived as the next generation Web Test Automation Tool.

Is Puppeteer better than Selenium? The answer is 'No', and I will cover 'why' in detail during this talk. I will show some live examples to demonstrate that Selenium can also do all those advance things which Puppeteer promises to do.

Software Craftsmanship is a practice of continuous development and helping others learn the craft. As the world is evolving towards the era of scripting language, we will be sharing our experience of how we have grown as a team of all QA with programming language background to the niche typescript world contributor.
During this talk, we will be focussing on the shift of existing selenium to the actual implementation of Protractor test API. How and when to use a protractor? When to pick protractor as an automation tool for building a framework.

By the end of the session, one will be able to understand how can we start working on end to end tests for any JavaScript and TypeScript based application using Protractor, Cucumber framework, and Page Object Model design pattern.

We will also talk about configuration files, cucumber, typescript, promise handling in protractor.

Selenoid is an alternative lightning fast open-source Selenium protocol implementation running browsers and Android emulators inside Docker containers. It is distributed with a set of ready-to-use Docker images corresponding to the majority of popular browser versions, has a one-command installation utility and works slightly more efficiently than traditional Selenium Grid.

This tutorial shows how to build efficient and scalable browser automation infrastructure using Selenoid and related tools. You will be taught why running browsers in containers is so efficient, how to easily install Selenoid and use its powerful features.

Problem Statement:

As part of SDLC process:

1. Is your product quality impacted due to a smaller number of QA resources available in the team?
2. Are you waiting for QA resources to certify your code every time when you deploy? Is this impacting your product lead time (Speed to Market)?
3. Is your Product delivery timelines are impacted due to last minute defects identified?
4. Do you have your QA resources only in one location, but you want to “follow-the-sun” approach for Software delivery across multiple locations?
5. Do you have manual testers who are not skilled in programming, but you want them to execute automated test scripts w/o any training efforts and automation setup?
6. Would you like your team more agile and cross functional with Delivery?
7. Would you like to increase your QA team’s productivity while they invest more time in script development rather than script execution?

If answer is ‘Yes’ for above questions, "Zero touch automation" is the solution for above challenges that we have been facing part of SDLC.

Solution: Zero touch automation with cutting-edge technologies

In this session, I will cover how we solved this problem using innovative solutions, Cutting-edge technologies like NLP (Natural language processing), AI & Cloud solutions.

You will learn how AI, NLP integrated with core automation components to achieve Zero touch automation.

This solution is not just revolutionary, it is paradigm shift in test automation to get results to your email with detailed analysis of failure categorization with recommended actions to users.

I will also cover how E2E automation will be driven with decisions taken by machines based on what user is looking for . There is no manual intervention in this process. NLP and AI play key role to help machines to take decisions.

We will also cover how we empowered developer/release manager/any team member/Manager to trigger the scripts from their cell phone and get the detailed execution report without having any automation software installed in their computer or Phone.

We will be demonstrating how the request will be initiated from User, understand the need from user using NLP & AI , Fetching the code from bitbucket to select appropriate automation scripts , running them on Selenoid/docker server , storing results to MongoDB , receiving email with test results and Failure analysis.

What is the value of zero touch automation?

1. Enable speed to market: Now that Developers does not need to wait for QA resource, Changes can be certified quickly and ready to push to production. Lead time will be significantly reduced.
2. Increase quality: Now that test automation is easy and it can run multiple times in each environment, most of the defects will be uncovered and addressed before code goes to production.
3. Ease of test execution: Test execution will be very easy, no automation or framework setup required from user side. Test execution can be done 24*7.
4. Productivity: Increase QA team’s Productivity to focus more on script development rather than focusing on script execution and failure analysis .

In my talk, I want to share several approaches that help to improve automation testing in your company.

Do you want to spend less time developing UI automated tests? Maybe you want to reduce boilerplate code in UI tests? Or you think it is time to improve Page Object pattern that has been used for more than 8 years?

My first point will be about how the interface can help us to represent a new vision of Page Object and what benefits we could get from it.

The second - modern methods for coverage measuring are good only for development. However, the amount of useful information from coverage reports is extremely small.

It will a journey about autotest coverage. Imagine, that your project manager asks you - Do we have autotests for these buttons (forms, pages) or what autotests cover these Rest APIs with 'special' query parameters? I will show you two simple solutions that allow you to evaluate the coverage of tests written by test automation specialists.

a) API tests. There is a swagger and during his execution, we also collect a swagger. We count coverage as a diff of two swaggers. We can see what is covered, what is not and what data used.

b) Web tests. During the execution of tests, we collect information about elements, pages, and actions. As a result, we have such a format: page -> elements -> actions -> tests. All information representing in Chrome Plugin, that I will share with you.

And last, I am going to consider what cons have current TMS (QA time management systems) and what to do if you want to make an automation-first strategy on your project? Moreover, you look for one TMS for developers and QAs/or you want to save the Allure report of all autotests in one place?

Here you are! Allure Server has already released. I will overview the most important features and how to start using it from scratch.

If you have an interest in the above themes come to my talk.

When it comes to creating a project we always search for ideas that are open-source, easily scalable, ready to use.

We as humans always have a tendency to grow and expand and when it comes to customizable infrastructure it's a big Yes.

In this talk, we will be focussing on how we can save the cost of actual servers with easily scalable and manageable open-source software using an open-source tool - selenium grid. How we set up the nodes and hub altogether to make cross-browser, multi-platform execution takes place.

This talk will answer the questions "Will you be able to run your automation scripts without connecting the USB cable to your device in a limited range?"

If we have to ask ourselves where is the mobile and when is it required? So the answer would be its 'Everywhere'!!

It's next to possible to imagine a day without looking at mobile or using apps for that matter- Google, Facebook, Whatsapp, etc.

When it comes to using it so testing comes hand-in-hand with it. As we develop applications over a mobile device, be it any platform ios, Andriod and windows we shall also think about usability and end-to-end testing.

In this talk, we will discuss how Appium worked as a bridge between devices and controllers.

One of the biggest limitations with most of the frameworks in selenium is that we need to wait till the end to get the final test case report. Only then we can raise the alert that a particular functionality is broken. By then, it may be too late! In addition to this, in most of the frameworks, the HTML report generated is hosted on our company's private network and we need to connect to the VPN if we are outside the office to open the report and check the related screenshots to see which test case has failed and why.

So, why not raise an alert as soon as the test case fails? And why not attach a screenshot along with that alert so that all the stakeholders can actually see what has failed in the application?

In this session, we will learn a simple yet a really useful way of sending an alert along with the failed test case screenshot by integrating slack with selenium which will help us alert all the stakeholders as soon as an automated test case fails so that everyone can react to it immediately and the damage will be minimised.

It is always challenging for us while dealing with Xpath and Css in iOS Mobile Automation.Even we can't think to do iOS native app mobile automation without them .

So problems we need to face are

• High Maintenance
• High Execution Time
• Complex installation
• Additional Web server

Do we have some solutions for this problem - The answer is Yes !!! -> KIF(Keep It Functional)

A key requirement for successful test automation is to get past the brittle or fragile nature of test scripts. Any Selenium (or Appium) developer has encountered the dreaded "NoSuchElement Exception". A locator that worked yesterday may fail today. What's a test engineer to do?

Fortunately the field of AI provides promising solutions and allows for the creation of self-healing tests. Tests that can find elements across all environments. Tests that can learn from "human-in-the-loop" intervention and work perfectly thereafter. Imagine automated tests that "just work"!

This session will look at how to apply the latest in AI and Machine Learning technologies to improve your test scripts. With the plethora of new open source AI libraries made available by companies such as Google, the ability to leverage AI in your applications is more accessible than ever.

This session will be a primer on AI technologies and how they can be utilized for perfect test automation.

Tesbo is a hybrid Test Framework built top on the Selenium which allows you to use the plain English language to define the test which helps you to reduce the development and maintenance time and efforts. sounds similar to the BDD framework (i.e. Cucumber, Specflow, Gauge, etc...) ??? But No It Isn't... It's much better than Cucumber.

In this session, we will look into why we have developed Tesbo and how it will reduce the development and maintenance times of web and mobile test script.

This session will focus on the

• Introduction of Tesbo
• Advantages of Tesbo
• Feature description
• Test Development and Execution demo
• Future plans for Tesbo

"Are you working for a product where you're struggling to automate the module(s) which you actually think can not be automated?"

Considering you have a product running on different browsers, different OS and/or different platforms and for this, you have written automation scripts in different technologies. So, following are the pain points which we are going through: -

• Automation candidates test-scripts can’t be automated

• Lower automation coverage

• Lesser auto-tests => more manual work.

• Lessor auto-tests => more regression time.

• No with-in sprint automation.

• Urge for the quick solution to cater to cross-technology and cross-platform automation scripts.

So, based on the above points, we came up with the automation architecture in such a way which serves the purpose in the following manner:

• Able to add more automation coverage in another layer of testing.
• Able to make a call from any platform (mobile or web) with any technology like Java, Swift, C#, etc.
• More automation coverage = Lesser manual effort during regression or Smoke testing.
  
  

Extensible Web Services Architecture Diagram

Extensible Services Components:

• Application: Responsibility: Application is the main Spring Boot Application and has the following responsibilities:
  • Triggers auto-configuration
  • Component scanning

• Controllers: Responsibility: Controllers are the Rest Controllers has the following responsibilities:
  • For restful services creation for CRUD operations
  • All the requests and response from the external automation framework is being catered via controllers

• Services: Responsibility: Services is the Business Logic layer where the CRUD operations can be performed based on the extended web-service calls. These operations can be performed on the product’s existing APIs and/or database using the data-access layer, below are the key responsibilities:
  • Business use-case based CRUD operations on the product database
  • Business use-case based CRUD operations on product existing web-services
  • Authentication of the product can be done internally via services based on credentials supplied from the controller params.

• DAO: Responsibility: DAO is the Data Access Layer where the CRUD operations can be performed on the product database.

Some of the actual problems and the solution:

Problem#1: Alerts - Dismiss for Today flow

• We have to wait for 24h to verify that the alerts section is displayed again

• Cannot run the same test on both platforms (web/mobile)

• Cannot run the same test twice in the same day

Solution: Unsupress the suppressed dialogue box by calling the extensive API can resolve the problem so that on re-run the automation it would not fail.

Problem#2: Tasks read status, once selecting a task, it is marked as read and cannot check it again.

Solution: Unread the task with simple extensive API call with taskId as a parameter

Implementation and usage

We have the implementation done on a product, and is utilized by 4 external automation frameworks, as below:

• API Automation Framework (Java)
• Web Automation Framework (.Net)
• Android Mobile Automation Framework (Java)
• iOS Mobile Automation Framework (Swift)

We can walk through with the implementation approach, as a

• Producer: How we actually produce the HTTP response for a test scenario via API call requested by the consumers.
• Consumer: How our consumers (external automation framework) can get the HTTP Response, they can use at their end to get the work done.

Time break-up and the speakers:

1. Introduction about the case-study 3min - Sahib
2. Problem and solution 5min - Amrit
3. Architecture diagram walk-through 5min - Sahib
4. Demo 5min - Amrit (running the demo) / Sahib (explaining the demo)
5. Q/A 2min (Both)

Every time you see flaky scripts you keep wondering what should I do .Should I change my locator strategy or should I use “Thread.sleep(“wait a minute should i really use this.. A big pause in your mind.”)” . Trust me flaky scripts are worst nightmares.

So here I will be sharing my journey how I have used test.ai in appium automation scripts and how I have converted my flaky scripts to green colour .

Apart from this I will also be talking about how you can integrate this in your appium automation framework.And how you can train this AI plugin according to your need.

As a bonus those who hate flakiness I will be talking about some limitations of this and where not to use in your scripts.