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

"All tests in today's automated regression run have been marked as Untested. What happened?"

"No notifications are being sent for test runs on the channel"

"I pulled latest code, and the framework dependency shows compilation error"

"What does this new method in the framework do?"

How often do you hear such things within your team?

As Quality champions, we need to walk the talk. When we expect our developers to write quality code, write unit tests, build features without introducing bugs, the onus lies on us (as test engineers) to do the same. With almost every test engineering team writing automated tests to check functionality of their products and services, it becomes very important to ensure that the test automation framework and the test scripts are bug-free and follow good standards of software engineering.

It cannot be stressed enough that test automation code should be as good as production code. In order to build production-quality test automation framework and scripts, a number of steps can be taken at:

1. Code & System Level

2. Process & People Level

Our test engineering team went through a transition from having random & unexpected failing test runs to having greater confidence in the quality of the tests. Learn from this case study of our journey to ensure that end-end UI automated tests are built with quality in mind. We will also see demonstration of some of the use cases.

With an ever increasing no of businesses being conducted on web the testing need to write automated tests for the app's UI is something that can never be ignored. As you all know Selenium provides an API that enables us to do this quite effectively.

However, when tasked with setting up the automation framework, there are a lot of questions that arise in the minds of aspiring test developers regardless of what level they are in their career.

Some of such questions are:

1. How does one actually go about the business of building a robust and effective automation framework on top of selenium?
2. What are the elementary building blocks to include in the framework that an aspiring automation developer should know of?
3. How should we model our tests? XUnit style vs BDD?
4. Are there good practices, sensible design patterns and abstractions that we can follow in our code?
5. What are some of the anti patterns/common mistakes we should avoid

A lot of literature, documentation and blogs exists on these topics on the web already.

However In this talk,

I would combine this existing knowledge and my years of experience in building automation frameworks and breakdown these elements and walk you through exactly the sort of decisions/considerations and practices that you can take while starting to implement or improve the UI automation for your team.

Hope to see you there!

So you have got a few UI tests and they are running in parallel, great! However, life will not be so sweet once these 'a few' turns into 'a lot'. We grew from a few to 1500 UI tests (although not particularly proud of this number, there are situations and reasons)

We started with a simple parallel distribution of tests 3 years ago. As test count increased failure count run time increased along with increased flaky tests. Mobile tests had their own challenges (eg. device dropping-off, random wi-fi issues, etc) To keep up with this, we created a queue and workers based solution which could distribute the tests more efficiently (https://github.com/badoo/parallel_cucumber). Over time, we made more improvements, in particular:

• Segregation of failures based on infrastructure issues and re-queue the tests
• If a device/emulator malfunction, rescue the tests to another device
• Repeating a single test on 100s of the worker in parallel to detect flakiness
• Repeat a test if a known network issue
• Terminating the build early if more than a certain number of tests have failed
• Health check of each device, before each test to ensure reliability
• Muting a test if failure is known, and highlight outdated mutes if the related task is fixed

In this talk, I will talk about the initial challenges with running UI tests in parallel (Selenium and Appium), how we approached the queue based solution and continuous improvement of this solution; finally, how attendees can use it at their workplace or create their own solution based on our learnings.

There are dozens of matured docker based solutions available in the market for Android automation testing,

but

what about iOS testing?

It’s hard to create and maintain the docker based solution for iOS testing since it demands the Xcode and for the optimal performance the system needs the Apple certified hardware.

Combining Ansible with Selenium Grid yields a powerful combination because it allows us to set-up our grid and nodes in just a few seconds. In this talk I will demonstrate how to use simulators to build a reliable and scalable in-house iOS simulator lab using Ansible, Selenium Grid and Appium.

There are already over 200 million users consuming VR applications by 2018. And with Google, Mozilla pushing WebXR capabilities in browser and vendors like BBC, Amnesty International, Universal, Disney, Lenskart and a lot of them adopting them to their websites, we will soon see a huge rise i demand for Web VR and Mixed Reality applications.

But how do you test them in scale? How do you define "smooth" as opposed to just responsive?

In this talk I will go over some key details about the WebXR specification. The work that Mozilla, Google and the W3C Immersive Web Group is doing. The differences between testing a regular web page and a Mixed Reality enabled one. What to watch for and how you can automate it.

It can be intimidating for inexperienced teams embarking on their test automation journey for an existing code base. There is so much to test, and so many ways to test. I often see teams stuck with debating on where to start and what tools to use and best practices:

"We should start from unit tests"

"No, integration tests are better!"

"Should we use tool A or tool B?"

I see this play out all the time, and I've been there before. And the worst that could happen is decision paralysis and inaction.

The bigger question really is "What to test?".

My rule of thumb is "Start with the scariest code". I'll share with you my framework for evaluating the ROI of writing a test for a feature and prioritising what to test.

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.

We learn more from our failures than our successes. I want to share one of my failure stories, where I learned that coding is not the most important task in Test Automation.

A failure taught me that coding is not the most important task in Test Automation. I fixed a bug, added tests, and shipped it to production. After that, a bug report came in showing that the fix created a new bug. I felt bad, I did not understand how that happened. A hotfix solved the issue, but the root cause was not addressed: what did I miss?

By taking a step back, I understood the situation, it all happened by overseeing basic concepts in testing (like understanding how the system works). The problem was that coding had more priority than creating a test plan. After this, I prioritized tasks better to avoid this situation to happen again.

This talk shows that testing concepts are more important than ever, in a time where tools promise to do everything, we focus less on what and how to test, and more in using tools to test. It outlines how a test strategy can leverage a continuous testing setup. Finally, it shows that failing is ok, but failing again for the same reasons is not.

Problem Statement:

While running thousands of automated test scripts on every nightly test schedule, we see a mixed test result of pass and failures. The problem begins when there is a heap of failed tests, we caught in the test-automation trap: unable to complete the test-failure triage from a preceding automated test run before the next testable build was released.

Deep Learning Model:

The classification was achieved by introducing Machine Learning in the initial months and followed by Deep Learning algorithms into our Selenium, Appium automation tests. Our major classification was based on the failed test cases: Script, Data, Environment, and Application Under Test and that internally had hundreds of sub-classifications.

To overcome this problem, we started to build and train an AI using Deep Learning, which simulates a human to categorize the test case result suite. Based on the test result failure for each test, the AI model would predict an outcome through API, categorizes and prioritize on the scale of 0 to 1. Based on the prediction model, the algorithm takes appropriate response actions on those test cases that are failed like re-run test again or run for different capabilities. We kick-started this by gathering the historical data set of 1.6 million records, which was collected over a 12 months period, data including the behavior of the test case execution and the resulting suite.

This Deep Learning-based algorithm has been provided the quality to break down the new defects based on its category, and a classification score is given on a scale of 0-1. We’ve also established a cutoff threshold based on its accuracy of improving, and to group the failed test cases based on its similarity. Classification of the test cases is done in high granularity for sophisticated analysis, and our statistical report states that the classification of the defects has been increased with 87% accuracy over a year. The system has been built based on the feedback adapting models, where for each right classification it will be rewarded and for the wrong, a penalty is given. So whenever receiving a penalty the system will automatically enhance itself for the next execution.

The algorithm has a powerful model for detecting false-positive test results calculated using the snapshot comparisons, test steps count, script execution time and the log messages. Also, the model has been built with other features like – duplicate failure detection, re-try algorithms and defect logging API, etc.

The entire classification system has been packaged and deployed in the cloud where it can be used as a REST service. The application has been built with its own reinforcement learning where it uses the classification score to enhance itself and this is programmed to perform in an inconclusive range.

In sum, this deep learning solution can assist all Selenium testers to classify their test results in no-time and can assist to take next steps automatically and allow team could focus its efforts on new test failures.

Link: https://github.com/testleaf-software/reinforced-selenium-test-execution

GitLab is the first single application for the entire DevOps cycle. Only GitLab enables Concurrent DevOps, unlocking organizations from the constraints of the toolchain. GitLab provides unmatched visibility, higher levels of efficiency, and comprehensive governance. This makes the software lifecycle 200% faster, radically improving the speed of business.

Taking into account the fast growth of GitLab in recent years and it’s prominent advantages, you might be required to start running Selenium tests in GitLab or even migrate your end2end tests from your previous CI tool to GitLab.

Step by step guide will provide you the main challenges, key configurations, pitfalls in order to integrate and successfully run Selenium tests in GitLab CI. The wrapper around the Selenium to be presented is going to be Protractor with a built-in Jasmine test runner.

The presentation will also showcase some main tips and tricks we’ve faced during this integration at our fast-growing startup in Munich, Germany.

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.

Best Practices - How to get the best 'Return ON Investment' (ROI) from your Test Automation.

This has been observed that, most of the test frameworks wont be able to survive due to lack of expertise, no maintenance, no best practices being followed, and finally your test automation will be dead after few months, and there is no "Return ON Investment" from this. This is the most common problem, most of the companies are struggling and finally back to square to the Manual testing.

My proposal : HOW to leverage your test automation in terms of best practices, best ROI, and how to adopt best automation culture in your organisation.

I strongly propose some of the important points/suggestions to achieve this in your Organisation/Team.

1. Test Automation Practices:

• Design Patterns (Web/Mobile/API)
• What to Automate/Not to Automate

2. Common Automation Frameworks at Org Level:

• How to design Generic Utilities, Libraries and different Components, which can be suitable for all the teams in the same Org.
• Best practices to design your Tests (Automation).
  • Common Design Patterns
  • Common application level and Page libraries
  • Best Practices to use Assertions in your Tests (How and What to write for assertions). Most of the people don't write proper assertions and this is making your test unreliable and no defects found during execution.

3. Inclusion of API/Backend libraries in your UI test automation as an external Maven/Gradle Dependencies to avoid un-necessary tasks, some of the important points to be considered here:

• User Creation from APIs (No need to automate user creation from web/app for all the test cases)
• API tests are stabled most of the time
• API calls takes lesser time as compared to web, hence include API calls in your UI/App framework to save time.
• Less flaky test

4. Best Code Review Process (Do not merge your code into Master without proper Code Review)

• Implement PR (PULL Request) Process
• Static Code Analysis using SonarQube, Cobertura, JACOCO etc..
• Get the benefits of Best Test Automation Quality Matrices
• Sometimes, Manual (Functional Tester) should review your code (Assertion, test steps and use cases) to get the best coverage

5. Quality is A Team responsibility:

• Developers, POs, Manual QEs and Automation engineers should be included to get an overview of test automation coverage.

6. Maintenance of the Frameworks

• After couple of months, it should not make your life miserable if you don't maintain your libraries and framework properly.
• Do not use Hard Coded values, make it simple and Generic.

7. Infrastructure Setup for Test Design and Test Execution:

• Proper Browser - OS lab setup
• Proper Mobile Labs setup with different Devices - IOT, iOS, Android, iPad, Tablets
• Proper CI - CD common configuration using Jenkins, Dev Ops, AWS, Docker and Cloud setup
• Handling multiple Docker nodes using Kubernates (use of Selenoid, GRID on Cloud)

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 .

The best engineering teams are releasing code hundreds of times in a day. This is supported by a test setup that is not just fast, but robust and accurate at the same time.

We look at data (anonymized) from millions of tests running on BrowserStack, to figure out the very best test setups. We also analyze the testing behavior of these companies—how do they test, how frequently do they test, how many device-browser-OS combinations do they test on. Do they gain speed by running more parallels or leaner test setups?

Finally, we see how these steps help these teams to test faster and release continuously, and how it ties-in to the larger engineering strategy.

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.

Quality Assurance is an important term in the lifecycle of a software product. When it comes to QA, there are a lot of layers of testing which includes but not limited to Unit testing, Integration testing, UI testing. If we consider the test pyramid, although UI testing forms only a small percentage of the tests, it's an important factor in deciding the quality of the product. One of the main pain points in having a UI test is the execution time. To overcome this, we now have the tests that are executed in parallel. While designing a test infrastructure for executing the UI tests in parallel, there are a lot of factors that need to be considered. Some of them are

• Scalability
• Reliability
• Resource constraints

Taking into account the different tools which are available now in the market, one of the most efficient tool which satisfies the above criteria is "Selenoid"

Selenoid is a powerful Go implementation of original Selenium hub code. It is using Docker to launch browsers. One of the main advantages of selenoid is that its' lightning fast. Selenoid launches a new container for each new browser request and stops it after the session is closed. A certain browser version, the required version of the web driver which supports this browser and all necessary dependencies form each container. Selenoid also support most of the popular browsers such as Chrome, firefox etc.

This presentation will be to show case how to create a scalable selenoid infrastructure in AWS cloud with the help of kubernetes and this is being used at our fast growing startup based on Munich, Germany. We will also show case the comparison between different tools that are available in the market.

Architecture

https://drive.google.com/file/d/1Uz5S2KEyCYHNqarppU9HA4zMdkahzIuY/preview

The ‘make’ command has been around since 1976 and was originally used to build executable programs. In this talk I want to show how this powerful tool can greatly reduce complexity and eliminate stumbling blocks of running your automated tests. This applies to both CI pipelines and local test runs on developer or QA machines.

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.

We are now living in the age of Big Data. What makes Big Data so special is its ability to help the common man process petabytes of data to build innovative solutions. Cloud has played a pivotal role in building this data economy by making infrastructure more cost effective and enabling easy scalability.

Today, the abundance of data helps business make intelligent decisions through business process automation. Data drives all our digital interactions, starting from products that we see on our Amazon home page, to our Netflix recommendations, to the advertisement on Google search results, to even the Friends that we get connected to on Facebook. All these systems are powered by data that is collected from the various system, cleaned, transformed and stored into Big Data solutions. Testing of these data systems have become very complex and requires a new approach. This paper highlights various aspects of Big Data Testing including:

• Complexity in testing Big Data systems

• Cloud based tools for testing Big Data cross various stages

• Simplification of test processes and visualization through dashboards

• Testing Big Data in the Agile/ DevOps