Speakers & talks

In 2017 I told you to care more about your infrastucture than your scripts. In 2018 I showed you a framework to help you with it. This year the theory meets reality and we actually deploy something.

On Stage.

Securely.

Entirely through code.

And while that runs in a window, we'll discuss what makes your automation infrastructure secure, scalable and cost efficient.

This session will use Terraform and AWS, but the concepts are applicable to any cloud deployment.

Note: You don't need to have seen Parts 1 and 2 to get value from this, just a desire not to be the one responsible for a security breach or to cause your employer to have unnecessary operating expenditure.

Automation framework development is an acquired skill and can be considered similar to application development. The framework would greatly improve if the design principles used to write application code are leveraged to build it. By leveraging the 4 pillars of Object Oriented Programming in writing your automation framework, we can achieve the same level of efficiency as your application. Here are a few quick examples:

• Abstraction - use of different browsers to enable the test case to be run on many different system configurations.
• Encapsulation - use of page objects as a class.
• Inheritance - keep common functionality in parent Page class and extend it for all other child Page classes.
• Polymorphism - ability to change behavior at runtime

Software development is built on the foundation of reusability and reliability. By making the steps in scenarios reusable and scenarios or test cases independent, we can lower the test maintenance costs and improve stability.

Prerequisite

Learning Outcomes

We should have a code of ethics in whatever we do because it allows us to measure our decisions against our values. An engineer is first and foremost a human being, but sometimes engineers ignore ethics and ship unethical features to users. With this talk I will explain why people push unethical code into production and ways that we can prevent that from happening.

Development does not exist in a vacuum. Society is the biggest system we can impact and everything you do is a part of that system, good and bad. Ultimately we must judge the weight and value of our work based on that impact.

Sometimes engineers ignore ethics and ship unethical features or outright products to users. With this talk, I will answer some questions such as:

• What’s the code of ethics of an engineer?
• Why many of the engineers that are working on products tend to not follow this code and push “unethical” code to production?
• What are some examples of unethical features pushed to production?
• What we can do as a community to persuade people to follow this code of ethics?

I believe that we have a duty as people building products for people on the other end of the screen, to build a product that they can love and trust. But we can only do that if we ourselves are transparent and straightforward in the way we do so and the route we take to get there.

We all know Selenium tests are flaky by nature, slow to run, expensive to maintain and finding the root cause of a failure is not always easy. I would like to show you how we shifted our UI tests left. This drastically limited the number of Selenium tests we needed to write, which made us able to focus our Selenium testing on areas where it actually adds value instead of creating a headache.

The best way to truly achieve Agile and CI/CD is to have devs fall in love with your tests - manual or automated. This transformation starts with empathy and ends with confidence. This is what I did at my current company and now every member of the team enjoys writing automated tests.

Security has become a necessity in our day-to-day activities. Are we aware how we can uncover these vulnerabilities? Do we understand the basic security tests that we run? Can we analyze and understand whether the threat found is a false positive or not? How can we make Static Application Security Testing and Dynamic Application Security Testing (DAST) work hand in hand for our benefit? How can we have DAST Automated with our dear Selenium? How can we apply DAST on Mobile Apps? How can we have DAST part of CI/CD pipeline?

This talk will introduce the audience to take their very own first steps in to Security Testing. I will be introducing them to concepts and move forward on how they can achieve them with real demos which will comprise of giving the audience an overview on certain OWASP vulnerabilities with demos on them and then demos on Mobile DAST and Web Application DAST with Selenium and Jenkins.

This will be a helpful talk for those who are interested to step into the world of security testing.

Conservancy is home to over 40 community-driven open source projects -- including Selenium. This talk is about the structures that facilitate the sharing of everything *around* the software that community projects need in order to thrive and do good in the world.

I’ll share details about open sourced AI-powered test-automation dashboard — ReportPortal.io. Use case of machine learning in test automation log processing and test fail categorization. With benefits of real-time reporting from multiplied, distributed or remote environments. You will learn how to start it on you project, organize dashboards and metrics tracking. Leverage API of the tool for integration with you CI tools like Jenkins.

With changes to and increasing enforcement of accessibility Laws around the world, implementing a strong testing strategy early in the product development cycle is key to not only meeting these Laws but an overarching improved user experience for everyone. This presentation will discuss how implementing accessibility into unit testing has helped us improve our ability to catch issues sooner in addition to the following:

• Technical aspects of implementing the tool
• General pros and cons of using any automated accessibility testing tool
• And of course the Web Content Accessibility Guidelines, Section 508 (United States), and EU 301 549 (European Union)

Chrome DevTools is one of the most useful web developer tools. It allows you to get comprehensive information about the page and requests and emulate mobile browsers on slow devices.

Some of the blockers which we faced with Webdriver was to automate

• Getting events from browser like when specific network call completed
• Setting the fake geo-location from your WebDriver scripts
• Updating the user-agent
• Mocking the web response by intercepting the traffic
• Simulating network bandwidth especially for Mobile Chrome

As our team had built a good number of a test case with user-journeys it was hard for us to move out of Webdriver and rewrite all our tests. So we decided to take the advantage of chrome dev tools API which uses web socket communication and implements our selenium web driver test to access all the API.

An outcome of Session:

We will demo about how you can use the power of DevTools in Selenium tests and how to make the debugging more convenient.

In my experience, test code does not get treated with high coding standards as application code does, because as many people tend to say: "it's just for testing". As testing is a critical part of the SDLC, why not?

By applying linting (static code analysis) tools to test code, preferably the same tools as for application code, tests can be improved which can eventually lead to better maintainability, readability and more robust tests.

When your team gets new developers, how do you prepare to help them thrive? Most of us believe we are encouraging and inviting to new team members. Hiring developers can be expensive. As an industry, we still have a turnover problem, costing us time, money, and technical excellence. What you do in real time, solving business problems, defines your team culture. Hear real life examples of experienced developers attempting to help me learn in my first few years of programming. I'll share some mistakes that you may be unintentionally making that could harm the confidence and growth of your new programmers, and several tips for quickly boosting the experience and learning of the developer you are interacting with.

The story of my major blunders and lessons learned throughout the 7 years that I’ve spent as the only member of the Test Automation Team, designing and developing the company’s automated testing framework “from scratch”. I had to learn the hard way that, while, in a world of Software Testers, the Test Automation Engineer is seen as a superhero – with great power come endless possibilities of messing things up!

Full stack UI driven tests are routinely criticised and shown to be inefficient, wasteful and brittle. But what are the alternatives? How can we successfully move away from full stack tests and develop valuable automated tests? We can achieve this by using our knowledge of our systems along with task analysis techniques to identify opportunities to move away from fill stack tests and towards smaller, focused, tests that are more maintainable, give better feedback and are fast to run.

In this talk, I will introduce and demonstrate task analysis techniques that can help us break down a system. We will identify the different technologies a system is comprised of, the actions each technology carry out and their integration with other parts of the system. From there, we will learn how these actions and integrations can have automated tests run against them using a varied range of automation tools. Examples would include JavaScript unit tests for JS components, Visual comparison tests for rendered HTML and API tests for contract changes between services.

Through the demonstration of task analysis and range of tools, we will learn that by breaking down a complex action, we can identify and create multiple targeted tests that when ran together give us richer feedback and are more maintainable than a full stack test can.

By the end of this session, attendees will be able to:

• Describe the task analysis process and its value when applied to complex systems
• Break down a complex system using task analysis to identify specific system actions
• Review specific system actions to help identify different automated testing activities
• Produce automated tests that run against specific system actions that when combined give us a wider view of our systems current state

Since many years and up until now! Testers have focused on functionality, ensuring the applications are performing and working correctly per protocols. While most companies are struggling with the transition into shorter release cycles and faster deployments, the QA process itself considered as an afterthought.

However, in today's digital era with so many competition having your application functionally available is not the only requirement but also delivering apps that are pleasing and inclusive to all the everyday users are a 'necessity'. The organizational strategy and especially testers must examine the UI/UX aspect of their applications to deliver apps flawlessly that are Pleasant(Usability), Visually perfect and Inclusive(Accessibility) to use.

In this talk, Manoj will take us through his experience testing both UI and UX with practical examples, the importance of User Experience and User Interface through Quality Engineering. Also, how early the testing can start with various characteristics like Usability, Accessibility & CSS Testing with practical examples to accelerate the end-user experience

How do you tackle test automation for an e-commerce platform spanning 48 different brands in so many countries? The project started with one country but was built generically because all the brands worldwide would be onboarded in the upcoming years. New countries can be set up very quickly, which is the main goal and the proven strength of the project. Our test automation could not be the bottleneck in this rapidly expanding global ecommerce solution.

In order to avoid a lot of different frameworks/repos, we had to think of a way to make a scalable and generic test automation framework. Key to success is a combination of proper tooling (Cucumber, WebdriverIO), scalable set up/mindset and support within the project.

Currently, several brands are live and our framework has proven itself by its scalability, accessibility. Setting up a second brand, which was the first real “test” for our framework, mindset and way of working, was a matter of hours with some tweaking for minor brand specific elements. The third country went even faster and we can now include new brands into the framework on a daily base.

Remember the legend of the Pied Piper of Hamelin? He was known as the Rat-catcher. He played an enticing song on his pipe and the rats followed him mesmerised by his music. Who are the “rats” we want to control in Selenium? Mouse events and complex user gestures.

Unfortunately the mouse is often deaf and unresponsive to the code we play.

All of us can become like the The Pied Piper of Selenium and get those "rats" to dance to our tune.

Michelle will elaborate further on how we can achieve this and look at elementary mouse events and element attributes. She will look at how actions and interactions differ across programming languages, and in a variety of browsers and devices. Michelle will discuss the pros and cons of learning more about Javascript, and how executing JS can result in less painful scrolling, hovering and dragging. And a bit of chit-chat about using appropriate waits and sensible pauses when coding your interactions. The moral of the story. Keep your promises. Make those mouse simulations work.

Working at a game company, we needed a powerful test automation tool that could be used across our different games and engines. We thought of a solution that would do this and more and, in collaboration with Google, we created and open sourced the "Airtest Project". With its record and playback utility and the ability to create the test code built-in you can see how useful it can in any of your projects.

My first Stand Up as a Test Manager? Charlie slammed the door shouting that he needs clear instructions. Lucas stood in a corner, terrified in silence. Kevin told me that he will probably quit because it’s not fun anymore.

Petra, do you want to succeed? Then you have to adjust your communication style to the needs of your team.

Does Charlie want instructions? I will always write clear emails explaining what went on at the end of every meeting. Does Kevin want some creative challenge? He will get a new project. Will Lucas feel more comfortable in private? I will plan a lunch with him.

There are 4 personalities in your team!

1. Get to know yourself!

In the first part I will introduce you to these 4 colours of energy and how to easily recognise them. You will finally find out: a. What is your real value for a team? b. How do you behave in a good mood or stressed out?

2. Get to know your team!

We will focus on topics: a. How to communicate change? b. How to give feedback? c. How to motivate and which tasks to give to your team members? d. How to write a meeting invitation to get all the people (personalities) on a meeting?

I have held some parts of this Speech at European conferences last year and someone approached me every time with a big smile on their face screaming: 'Now I finally understand it, my team is blue and I’m yellow.' or 'Aha, that’s why I can’t really get on the same page with my Business Analyst.'

Prepare yourself, this will change your way of communication forever. At the end of my session, be ready for a funny and interactive colourful call to action.

When I first started as a tester at my current company over 7 years ago my team was contributing code to a monolithic application. Soon after we started building our first microservice(yay) and moving towards a service-oriented architecture. Then, in a what seemed like the blink of an eye, we went from one microservice to hundreds of them. It was then that I realised for the first time that the foundation of how the organisation worked was changing drastically. As a tester I went from owning my component to owning my team’s components to now owning all the components. We are no longer working in siloed teams but in squads across tribes in an internal open source model.

So now what? How do you tackle all the changes? How has the tester role changed? What are the new responsibilities and how do they fit in the overall picture? How do you work inside the squad, with other squads and other tribes? How does a feature get into production, what does automation look like? How about releasing and support or incident management?

Join me in this session where I will be sharing my personal experiences of recognising a pattern when organisations are changing, navigating through them and adapting ways of working to the new model. It’s about finding your voice and role in an ever changing world.

Test Automation, a term everyone in testing probably hears on a regular basis, but what is it? If we listen to consultancies and tool vendors, it’s the holy grail. If we listen to some gurus in the testing space it’s the current and future of testing. Others are more conservative. However, I commonly hear people say Test Automation when they actually mean Automated Testing, to be frank, they’ve become synonyms.

This confuses me. As a skilled tester I use automation and tools all the time, some I create, some I download, but automated tests they are not. I’ve built automation to help my team create data, I’ve built low tech dashboards and I’ve built tools to install my mobile app under test on as many devices as I could connect to my computer. I’ve written tiny little scripts they saved me hours on a weekly basis. All these tools provided a lot of value. I’m also built numerous architectures to do automated checking, which just like my tools provided a lot of value. My focus on all these occasions was my testing mission.

So, what is Test Automation? How can we succeed with it? What skills do we need to succeed with it? Questions I’ve been pondering for the last four years, and I think I finally have some answers. Not just answers though, I also have lots of actionable advice for you to take back to work. This advice will be woven between real examples like those listed above, exploring why I created them, the skills needed and how they helped me with my testing mission. To keep the balance, I’ll also be included lots of stories where my automated approach has failed and how I learnt from it.

Takeaways

Web-platform-tests is a large testsuite used to ensure browsers stay compliant to web standards and in doing so remain interoperable. Along with being run in most browsers as part of their CI system, we run the whole testsuite over a dozen times a day to provide a public dashboard for both those working on browsers and those more generally working on standards.

Running such a large testsuite, we’ve inevitably run into many of problems web developers often hit when writing tests using Selenium. We’ve often fought against flakiness (from our Python code calling WebDriver, from JS code running in the browser, and from browser bugs causing them to be inconsistent) as well as against browsers changing under us. They hope in this talk that attendees will gain a good understanding of how we tackled these problems and be able to apply them to their own tests.

What's been happening in the world of Selenium since the last SeleniumConf? In this talk, we'll cover Selenium 4, how the project is run, how you can participate, reminiscing on the Old Days, and reflect on something that at first doesn't appear to be related to Selenium, yet is intimately related to it.