Test Automation Beyond Java 8

Abstract
While most people are still using Java 8 from six years ago, new versions of the language are being released every six months! The latest versions provide an abundance of new features such as functional programming capabilities, switch expressions, local variable type inference, additions to the Stream API, new factory methods for Collections, text blocks and much more.

With so much content, your Java upgrade should be more than simply the update of a jar file. Your test code no longer has to be as verbose as it once was, meaning less code to write and maintain!

This talk will introduce the new features of Java 9 – 14 and provide examples of how these features can be used for test automation.

Key Takeaways

• Introduction of new features in the latest 6 releases of Java (9 – 14)
• Examples of how the features can be used for test automation projects
• Greater command of the programming language

Bio
Angie Jones is a Senior Developer Advocate who specializes in test automation strategies and techniques. She shares her wealth of knowledge by speaking at software conferences all over the world, teaching courses, and writing tutorials on angiejones.tech. Angie is known for her innovative and out-of-the-box thinking style which has resulted in more than 25 patented inventions in the US and China.

The Truth About Oracles

Abstract
There’s a tranquil air through the office, but it’s about to be disrupted by the all too common, but often encouraged, flash of red. POP! The red flies through the office catching everyone’s attention. It’s mostly greeted by curiosity, but several people are well on their way to seeing red themselves! “Is there a problem here?”, no, just the power of oracles.

There are numerous reasons a build can fail, but the one I’m going to be focusing on for this talk is failing automated checks. I absolutely love automated checks, they are a powerful force when it comes to delivering valuable software at pace. The speed at which they can provide actionable feedback is invaluable, but that actionable feedback is based on a well-designed oracle. If the term oracle is new to you, think about your assertions, but it’s important to note that oracles and assertions are not the same.

I’m going to share my journey of studying oracles with you, exploring how the identification of your oracle is crucial in the design of your automated checks. How tools should follow your oracle, and how dangerous it can be to design oracles based on your tools. Exploring the different types of oracles, and how understanding them impacts the feedback you gather, and your automation decisions. How costly the time spent understanding the reason your checks failed can be, and how this can be significantly reduced when a clear oracle is identified and the check built around it.

Every single one of you has oracles, utilises them, talks about them and creates them. Being aware of how that happens, what they are, and codifying them into your automated checks, will elevate your checks to new heights.

Key Takeaways

• Describe what oracles are
• Compare and contrast different types of oracles
• Identify the right tooling to codify your oracles
• Communicate the importance of oracles
• Understand where oracles come from
• Understand the importance of naming your checks to identify the oracle

Bio
Richard Bradshaw is an experienced tester, consultant, trainer and generally a friendly guy. He shares his passion for testing through consulting, training and giving presentations on a variety of topics relating to testing. With over 12 years of testing experience, he has a lot of insights in the world of testing and software development.

Richard is currently the BossBoss at the Ministry of Testing, co-creator of the Automation in Testing (AiT) namespace and blogs at https://automationintesting.com.

Setting Up Your Tests To Fail

Abstract
We often have automated UI tests for features that we know aren’t working right. Defects, API issues, and more…but when the team has decided that the behavior isn’t going to be fixed, what’s an automation engineer to do? Jenny Bramble suggests writing your tests to pass.

By creating tests that pass on the current expected behavior (even if it is objectively incorrect!), we can create tests that are meaningful and actionable because they return information on the current state of the application—without creating more failure fatigue in our team.

Key Takeaways

• Automated tests are information, not bug detection systems
• Automated tests should pass on EXPECTED behavior even if that behavior is objectively a defect (AKA designing to fail)
• TODOs, documentation, and other methods to keep your team informed of the expected behavior of your automation suite

Bio
Jenny came up through support and DevOps, before diving headlong into her career as a tester. Her love of support and the human side of problems lets her find a sweet spot between empathy for the user and empathy for her team. She’s done testing, support, or human interfacing for most of her career. She finds herself happiest when she’s making an impact on other people—whether it’s helping find issues in applications, speaking at events, or just grabbing coffee and chatting.

Breaking Boundaries Using Charles

Abstract
Quite often we struggle to test all scenarios due to the limitation of test data. This applies especially when apps rely on third-party services and testing at different territories is required. Depending on the testability of your product, it can be hard to check all corner cases if the production back-end must be used and cannot be tricked. With a proxy, you can change what will be displayed.

Charles Proxy is known as Man-In-The-Middle and is loaded with features. Charles not only allows us to learn more about how our app functions the way it does, but it also opens our eyes to an entirely new array of testing possibilities to explore, from visualizing a simple request to mocking data from an existing or non-existing endpoint. During this session, Suman will show you how Charles Proxy can help to identify the cause of the bug that relates to your app making/receiving network calls/responses.

Key Takeaways

• How to use Charles on iOS and Android devices
• Observing and modifying HTTP requests and responses
• Rewriting using map local and remote
• Network throttling
• Whitelist and blacklist URLs

Bio
Suman Bala is Quality Lead at Sky. She strives to mature testing practice as a key enabler to drive business change benefits and is a strong believer in test automation. She is a quality evangelist who is passionate about providing continuous value adds through leadership, problem-solving and encouraging efficiency. Suman is a co-organizer for the Ministry of Testing Leeds meet-up and actively involved in Women In Tech, Better Allies, and Grassroots Leader initiative groups.

Orchestrate Your Parallel Testing to Be a Symphony with TestNG

Abstract
When it comes to running parallel tests against the Selenium grid or Sauce Labs VMs, you don’t have to think about coordinating your resources (as much). But what if your resources are limited and you’re constrained by the number of devices of a specific OS/Browser version and you still want to run your tests in parallel? Is it still possible? This presentation will go into the depths of parallel testing with TestNG and provide you with tips and tricks on how to manage/coordinate your parallel executions.

Key Takeaways

• The do’s and don’ts of parallel testing
• An understanding of the strengths of TestNG (e.g. Listeners/Interceptors/Custom Annotations)
• Helpful tips for debugging

Bio
As QA Technical Architect with over 10 years of experience in the field of automated testing, Sergio Neves Barros has worked on automating technologies such as HTML 5, Canvas, Flash, native apps and REST APIs. He has contributed to the Appium project to expand its capabilities of testing with Safari on physical iOS devices. Throughout his career, he custom built many frameworks based on business needs and mentored others on the best practices of building/maintaining their own framework.

Beyond WebDriver

Abstract
WebDriver has been in use for many years and has been used in billions of tests the world over. Over the years the web has grown new features and developers have wanted to get more and more information from the browser and their web applications while running their tests.

In this talk, David Burns will describe how WebDriver is shifting to a new bidirectional communication model, which allows it to evolve and adapt, as well as offer new capabilities and features to testers. Although these new capabilities will open new ways of using WebDriver, they will also open up a new world of problems for automation. Come and peek into the future!

David will walk through all of these and show you a new world of possibilities so that we can make sure that we maintain your old tests and upgrade them to new features as they become available.

Key Takeaways

• New features coming to WebDriver
• Better waits
• Potential problems with moving to a dedicated connection during a test

Bio
David is the Chair of the W3C Browser Testing and Tools Working group and co-editor of the WebDriver specification, trying to ensure automation frameworks in browsers are interoperable. He was an engineering manager at Mozilla within Developer Experience working on tooling and infrastructure to help make a better web. David has been a core contributor on the Selenium project for over a decade supporting Firefox and the Python client bindings.

Accessibility Testing for Mobile Applications

Abstract
Imagine for a moment that all our mobile applications are inclusive for most of the disability profiles. Imagine that it is easy to redact acceptance criteria for accessibility, and that all QA team players are trained to test the E2E flow through immersive techniques. And if you really are a dreamer, imagine that the automation framework and emulator allow us to automatize easily all the accessibility acceptance criteria.

It might seem to be a utopic ideal that’s far from reality, but this talk will show you how to work towards this vision. The first step is to define, in collaboration with User Research and UX teams, the different user profiles to target. Designing and developing accessible screens for mobile applications is only the first step to reach the accessibility goal. But testing the accessibility of the application is challenging to say the least. You’ll learn what can be done now, and what we can hope for in the future.

Key Takeaways

• The different disability profiles that we should take into account when developing an application
• Accessibility rules for developers
• How to choose a testing tool for accessibility
• A discussion of what we can expect from the future

Bio
Jonathan Chacón is a blind researcher and developer in accessibility, usability and new technologies in Spain. As an accessibility software engineer at Cabify, he works with other teams to make all digital and physical user interfaces accessible for all user profiles.

Pinterest’s Philosophy of UI Testing

Abstract
At Pinterest we use UI testing as a tool to ensure quality and improve the quality of life for hundreds of developers. In scaling our UI testing, we’ve learned first hand what works and what doesn’t work. Eventually we cemented it into an internal guide for thinking about UI testing. This presentation will share how we think UI tests should be written and when they should not be written.

Key Takeaways

• An understanding of how UI test strategy fragmentation is an inevitable problem if not actively addressed
• How to align testing strategies between platforms (iOS, web, android)
• How to align testing strategies between teams
• How Pinterest scales UI testing

Bio
Ryan Cooke has worked at a series of small startups. At Pinterest, he found a lot of success in helping the Android team scale through a variety of regression testing. He also has taken over the company’s testing strategy. In his spare time, Ryan is also the reigning champion of Super Smash Bros tournaments featuring over 60 employees from a handful of San Francisco Tech Companies.

Accessibility Testing for Mobile Applications

Abstract
Imagine for a moment that all our mobile applications are inclusive for most of the disability profiles. Imagine that it is easy to redact acceptance criteria for accessibility, and that all QA team players are trained to test the E2E flow through immersive techniques. And if you really are a dreamer, imagine that the automation framework and emulator allow us to automatize easily all the accessibility acceptance criteria.

It might seem to be a utopic ideal that’s far from reality, but this talk will show you how to work towards this vision. The first step is to define, in collaboration with User Research and UX teams, the different user profiles to target. Designing and developing accessible screens for mobile applications is only the first step to reach the accessibility goal. But testing the accessibility of the application is challenging to say the least. You’ll learn what can be done now, and what we can hope for in the future.

Key Takeaways

• The different disability profiles that we should take into account when developing an application
• Accessibility rules for developers
• How to choose a testing tool for accessibility
• A discussion of what we can expect from the future

Bio
With more than 10 years of experience in QA and IT in general, Hélène is now Engineering Manager for a team of 10 QAs, in Cabify, a Spanish unicorn start up company. She participated in international projects in several industries: travel, ecommerce, mobility, etc. Hélène is a fervent advocate for diversity in tech, she has collaborated with a lot of initiatives to give more visibility to technical women.

Mobile Security Testing With Fuzzing – From Google Project Zero to ABN AMRO

Abstract
From Google Project Zero to dangerous state sponsored hackers, almost every recent mobile security vulnerability has been identified with Fuzzing.

At ABN AMRO we are introducing this methodology in our QA process as an effective, cost-efficient way to identify and later on fix security issues in our mobile applications.

Key Takeaways

• Zero days vulnerabilities in mobile apps
• Looking for bugs and vulnerabilities with Fuzzing
• Examples of Fuzzing
• Innovative ways of doing fuzzing: Neural Fuzzing
• Fuzzing mobile apps using Sauce Labs

Bio
Sergio Giucastro is a software engineer with a strong background in reverse engineering, hacking and IT security. In the last 10 years has been working on many commercial Android apps. He is currently working in ABN AMRO contributing to make the mobile applications (iOS and Android) safer.

Not Your Parents’ Automation – Practical Application of Non-Traditional Automation

Abstract
Most software companies have an automation initiative. Typically, these initiatives focus on “traditional automation,” using a software package to automate existing test cases or user stories. Not that there’s anything wrong with that; often, there is value in that method. However, if we use only this traditional approach, we miss opportunities to exploit the power of automation. Instead of focusing on test cases, what if we consider this: how can automation help me best do my job?

During this session, Paul Grizzaffi will share real-world examples where non-traditional automation (or “automation assist”) provided business value, highlighting cases where the traditional method could not have provided the same level of testing; you will hear High Volume Automated Testing (HiVAT) highlighted as one of these approaches. You will also hear thoughts to keep in mind when implementing automation assist and see examples of creating helpers from tools not traditionally used for automation.

Key Takeaways

• Traditional automation can be valuable, but do not be blinded by the typical approach
• Ways to utilize automation to help you do your job efficiently
• There is more than one way to use your tools

Bio
As a Principal Automation Architect at Magenic, Paul Grizzaffi creates technology solutions for testing, QE, and QA organizations, including automation assessments, implementations, and through activities benefiting the broader testing community. An accomplished keynote speaker and writer, Paul has spoken at national conferences and meetings; he’s a guest lecturer at UT Dallas. When not spending time with his twins, Paul enjoys sharing with and learning from other testing professional.

Dynamic Test Environments for Continuous Testing

Abstract
Continuous Testing initiatives cope with several issues, some of them are highly linked to environments and test data. End-to-end environments do not allow on-demand deployments, since they are usually shared across other applications and used by manual testers.
Using dynamic environments, which means on demand environment created from scratch for test execution, will help to resolve both these issues: to remove the collision with manual testing or other applications, and to control test data available for testing.

During this presentation, Valentin Guerlesquin will do a live demonstration of a continuous testing pipeline to create the infrastructure, deploy and stub the application, run automated tests, and destroy everything at the end. Every step will be explained, giving you the complete recipe for success in continuous testing.

Bio
Valentin has been a software testing professional for more than ten years. Valentin has worked in several roles, including test environment management, manual functional testing, mobile, and testing process improvement. He is an ISTQB full advanced and TMMi-certified professional. He has trained dozens of his peers in several organizations, from telecom to the aerospace industry to finance.

Learn How the Fannie Mae CRM Team Improved Developer Productivity and Speed to Increase Code Quality for Their Salesforce Application

Abstract
The Fannie Mae CRM team delivers Salesforce solutions interacting with several custom applications and external software integrations, for both internal and external business users.

In the early stages of application development, our developers from 8 different squads, would commit their code development to a Single Master branch. This practice consistently broke builds and delayed execution of Automation tests to the end-to-end testing period. Developers were only able to identify defects and fix them later in the development lifecycle.

As delayed automation testing became a bottleneck, it impacted code quality in production. Our team then set out to answer this question: How can we deliver faster feedback on tests to increase developer productivity?

Towards adopting a shift left approach, our developers transformed the CI/CD process and now execute component tests before they merge new code. This practice helped us identify defects early in the development lifecycle and has maintained a clean pipeline for the development community.

In this session you will learn how to integrate early component tests in the CI/CD process, establish and maintain a myriad of test suites thus increasing software code quality without compromising deadlines.

Bio
Carmerci Jimenez is a Salesforce Certified Administrator and Developer who currently works as a Software Development Engineer in Test at Fannie Mae focusing on developing fast and efficient automation frameworks for Salesforce Testing. She has over two years’ experience developing automation solutions using Sauce Labs with a focus on visual and functional testing implementations. Her passions include continuous integration, promoting innovative testing strategies, and bringing testing practices closer to the development phase.

Testing More to Testing Smarter: A Journey of Transformation Part 2

Abstract
Testing More to Testing Smarter: A Journey of Transformation Part 2 is a follow up from the Saucecon 2019 keynote. This talk provides insights from the perspective of the quality automation team and their journey to reduce build times from 1 hour to 10 mins.

Claude Jones, Sr. Director of Engineering, will challenge the audience that automating more is not always the best approach towards achieving your quality goals. This talk will focus on:

• Quality Automation Anti-patterns
• Cross-functional Team Collaboration
• Test Case Optimization Techniques and Strategies
• Infrastructure Scaling
• Leveraging the Power of Analytics

Walmart Labs is the tech arm of Walmart with the mission to provide a seamless omnichannel experience for customers whether shopping online or in-store. The technology solutions built by Walmart Labs serve over 2.4M customers weekly supported by 1.5M employees in the U.S. alone.

Bio
Claude Jones is a seasoned technical leader with over 15 years of experience. He has been with WalmartLabs for 6 years and is responsible for managing a distributed team of 60+ product, user experience, project management, architects, and engineers focused on building custom tools to improve the way Walmart develops and delivers eCommerce experiences across the web, native app, and stores.

Claude has a passion for bringing out the best in others and believes that anything is possible with hard work and dedication. In his spare time he runs the Elevate Foundation, that is an organization focused on helping others in need and giving back to the community.

What’s in a Name? Metadata for Fun and Profit.

Abstract
We’ll start with a rundown of what makes useful Metadata, and what Metadata is, exactly. We’ll move on to looking at why test names should be Fables, not Filing Cabinets, learning what makes test names good, and what makes them bad.

We’ll talk briefly about test Status and how Exceptions aren’t Exactly Errors, before covering how and why to use Build IDs, Tags, and Custom Data.

This talk is for everyone in QE; we’ll have minimal code examples, no assumption of prior knowledge and most of what we’ll cover applies to non-Sauce Labs customers.

Key Takeaways

• Practical information about how to best name tests
• The ability to think more critically about test failures
• Suggestions on how to use tags, build IDs and custom data to organize and share tests better

Bio
Dylan has worked for Sauce Labs for seven years, helping customers learn & solving problems. His passion is sharing knowledge and making people’s lives easier through technology, which he’s been doing for 14 years. He’s been involved in Evangelism, QE & Development, as well as Product Design and Marketing across Fintech, Transportation, Data Warehousing and Health. He promises he’s not as boring as he sounds; Follow him on Twitter, @dylanlacey, and he’ll prove it!

Testing the Mesh – In a Culture of On-Prem

Abstract
Modern cloud-native business apps are inherently distributed, introducing immense challenges across the complete development lifecycle. They require new ways of developing, deploying, and delivering apps, resulting in a total overhaul of the production process. Breaking down historically-grown monoliths and forming smaller building blocks is critical to reduce per-tenant cost, promote agility, and facilitate seamless integration.

SAP piloted the approach with some of its products – facilitating change – both in technology and in cultural aspects. With modern tools, complex microservice applications are delivered daily, implicitly ensuring high-quality standards by using innovative automation and testing techniques. To ensure business continuity and keep customers’ mission-critical processes running, we’re using feature toggle configurations, A/B activation strategies, and strong resilience.

Key Takeaways

• Cultural change and flexible tools are equally critical for overall success
• Get the teams engaged – everybody’s responsible for product quality
• Speed matters – aim for the lowest possible meantime from commit to testing results
• Integrate early – to avoid late surprises and frustration
• Importance of unit vs solution-level testing

Bio
Damian is an Associate Development Architect working on tools for delivering cloud-native SaaS applications. Very early on in his development career, he found his true passion: front-end technologies. After joining SAP in 2012, he has been looking into the newest UI related technologies and spreading them throughout the company, including Vue.js, GraphQL, and many more. Together with his team, he builds tools to not only improve developer experience but also to raise quality awareness for the whole solution.

1 Codebase, 2 Mobile Platforms: How to test iOS and Android by just writing tests once

Abstract
Developing consistent mobile apps on iOS and Android is difficult enough, but writing automated end to end tests so they run on both platforms without writing them twice is even harder. The limited selectors on mobile make it very difficult to only use one testing code base for both platforms. By using accessibilityId’s with translation keys in the same way as in the app, we use the fastest and least brittle selector on mobile possible, being resistant to tests breaking in case of text changes, allowing to also check the app in all languages without any additional effort.

Using a hybrid framework like React Native or NativeScript with WebdriverIO, François will show how to use utility methods to cleverly encapsulate all of the platform differences as much as possible, so writing tests is efficient, readable and maintainable.

Key takeaways

• Learn how to apply approaches from developing multi-platform apps with just one codebase (as used in NativeScript, React Native and Flutter) to end-to-end test automation
• Get to know how to easily write tests in a way you can have them run on multiple platforms (even at the same time!) by just writing tests once
• Find out which selectors to use for testing multi-platform apps with the least effort possible
• Learn about testing accessibility and internationalization without any additional effort
• Increase maintainability and readability of your automated end-to-end tests

Bio
François Martin fell in love with test automation while studying computer science. He began working as a consultant in test automation engineering at SwissQ and enabled clients to test all stories automated every sprint. In his current project, he introduced Sauce Labs in order to deploy every two weeks at the Swiss Post and came up with a lot of clever ways to reduce platform specific code to a minimum, so the team can work fast and continuously test iOS and Android.

Not Just Accessibility IDs: Speed Up Your Appium Tests for Faster Feedback

Abstract
You want to be able to deliver at speed, so you want test automation for your mobile apps. But your suite is large. The tests are slow. You run them overnight. You split the tests over nodes. But it still takes hours to run. In this session, Hugh McCamphill will discuss a number of ways his team was able to speed up Appium tests to run 20-40% faster, beyond the use of accessibility IDs; for example:

• Which Appium capabilities sped up our tests
• Which Appium abstractions slowed us down
• The value of reusing discovered elements

Key Takeaways

• How to better understand what is time-consuming in a test
• The value of and how to rethink assertions to reduce test execution time
• Multiple strategies are required to speed up tests

Bio
Hugh McCamphill has been involved in testing for more than 15 years. While interested in all areas of testing, he specializes in test automation. He is currently a Test Engineering Manager with ShopKeep in Belfast. Hugh is also keenly involved in the testing community and organizes the Belfast Selenium Meetup since 2013. He also helps organize the Software Testing Clinic in Belfast.

The Perfect Score: How Quick Base Aced the Continuous Testing Benchmark

Abstract
Continuous Testing is a proven method to help engineering organizations deliver better quality software faster. However, for many teams it can seem like an insurmountable effort. With cultural hurdles, technical challenges, and a variety of stakeholders involved, it is often a long and arduous journey to the Continuous Testing “promised land.” However, when equipped with a plan for success, measurable goals, and a unified team working together, results are achievable.

This session will focus on:

• How to ensure that quality has a seat at the executive table, creating alignment on testing strategy from the beginning.
• Implementing “drama-free” technologies and consistent practices that are optimized for broad adoption across multiple development teams.
• The ongoing partnership between QA and Development teams, and how to provide continued engagement, support and education.

Using this foundation, Karen will show how Quick Base drastically improved its quality outcomes, increased efficiency by breaking down collaboration barriers with development teams, and created a true culture of quality in her organization.

Bio
Karen Motyka has been in the quality industry for a number of years and in a management role for the past 12 years. She established and manages both a System Quality Team and a Quality Community of Practice at Quick Base. Focus within these groups has been on supporting framework, infrastructure, and tools needs, enabling teams to move more quickly through process and best practice advancement, and up-leveling quality expertise across the organization. She’s passionate about quality (of course), leadership, and team management. She’s received leadership awards from several programs including the Women Unlimited LEAD Program and Dale Carnegie.

Testing the Mesh – In a Culture of On-Prem

Abstract
Modern cloud-native business apps are inherently distributed, introducing immense challenges across the complete development lifecycle. They require new ways of developing, deploying, and delivering apps, resulting in a total overhaul of the production process. Breaking down historically-grown monoliths and forming smaller building blocks is critical to reduce per-tenant cost, promote agility, and facilitate seamless integration.

SAP piloted the approach with some of its products – facilitating change – both in technology and in cultural aspects. With modern tools, complex microservice applications are delivered daily, implicitly ensuring high-quality standards by using innovative automation and testing techniques. To ensure business continuity and keep customers’ mission-critical processes running, we’re using feature toggle configurations, A/B activation strategies, and strong resilience.

Key Takeaways

• Cultural change and flexible tools are equally critical for overall success
• Get the teams engaged – everybody’s responsible for product quality
• Speed matters – aim for the lowest possible meantime from commit to testing results
• Integrate early – to avoid late surprises and frustration
• Importance of unit vs solution-level testing

Bio
Sarah has worked at SAP since 2013, starting as a student working for different on-premise departments and then joining one of the first SAP cloud-native application projects as a full-stack developer. Focusing on topics like UI infrastructure, software lifecycle management and test automation, her tasks ranged from the development of release engineering tools, setting up qualification pipelines to upskilling other teams in test automation best practices and tools.

Let Me Tell You a Real Story about our Mobile CI/CD

Abstract
In this session, Moataz Nabil will tell the story behind why Delivery Hero adopted native test frameworks for mobile testing. Since using Espresso and XCUITest is still relatively uncommon for large apps and there are various unique challenges, he will share the Delivery Hero team’s experiences, including:

• A brief architectural overview of the mobile test framework: why it is all native (Swift and Java/Kotlin)
• The advantages and limitations of this choice
• How they are running different test suites and scopes with CI and cloud devices
• Running the tests using different CI/CD pipelines for different apps, different countries and different scope using parameters
• How they make tests reliable: faking address and using features configs

Key Takeaways

• Details of the journey toward our Mobile CI/CD pipeline
• How they are adopting Mobile DevOps and the challenges that we had
• The advantages of using Mobile DevOps
• Why they believe in test automation as one team (shifting the culture)
• Why they are using native mobile test automation tools (Espresso and XCUITest)
• About the tech stack, workflows, and processes in their Mobile CI/CD
• The lessons they learned from our journey and what’s next in our plan (toward AI and Machine Learning in Test Automation)

Bio
Moataz Nabil has 10+ years of IT experience across development and testing roles across industries including agriculture, telecom, healthcare, fashion, and now food delivery. He is currently working as a Senior SDET/Test Automation Engineer at Delivery Hero. He has extensive experience designing test automation frameworks for Web and Mobile applications using a different set of tools and languages and implementing different CI/CD pipeline using different tools.

A Beginner’s Guide to Test Automation

Abstract
The options for automation are wide open, and you may feel overwhelmed with questions when you’re getting started: “What tool should I use? Which tests should I automate? Why is automation useful for us?”

The goal of automation is to create anti-fragile tests that are easy to understand and maintain. I’ll help you achieve that goal by answering questions that I ran into when I first started.

Key Takeaways

• What to consider when you’re choosing a tool or framework
• How to decide which tests to automate
• Best practices for writing the tests, like granularity and failure messages
• A feeling of confidence that you know how to get started

Bio
Angela Riggs believes that empathy and curiosity are driving forces of quality. She appreciates the hikers’ approach of “leave it better than you found it” and strives to do the same, whether it’s people, processes, or the organization as a whole. Her experience ranges from feature testing to leading company-wide process changes, and she enjoys her work most when she is supporting people to do their best work. Angela is also a strong advocate for a safe and inclusive environment.

NativeScript’s Journey to Mobile CI in the Cloud with Appium, Travis and Sauce Labs

Abstract
When it comes to testing open source software, you should have a primer showing the community how to use best practices to achieve a stable CI process, visible to all. And if something must be accessible from everywhere and from everyone, there is one place to do that—the cloud.

In this session, Dimitar Todorov will show one of their approaches to transparent CI process in the cloud with zero local infrastructure, using popular services like Travis-CI, Sauce Labs and GitHub. The session will also provide visibility for contributors and product owners on how it works and how quality of the software is achieved.

Bio
Dimitar Todorov has been testing software for more than 7 years now and has worked on different projects and cloud platforms for mobile application development. He is currently working on the NativeScript team as a Senior Automation QA engineer. His passions include continuous Integration, performance testing, and automation, and he has experience in almost every aspect of software testing. Dimitar is certified with all advanced ISTQB certificates and is especially interested in mobile application testing.

Sauce Connect On Demand – A Flexible Tunnel Strategy

Abstract
The test automation team at Dell has expanded its offering for their development teams since they started running Sauce Connect on Kubernetes. Morgan Vergara noticed that since they can quickly and easily create tunnels using Kubernetes, they began receiving a lot of ad-hoc tunnel requests. Rather than continuing to respond to these requests manually, they did what any developer would do: they automated it.

In this session, Morgan will describe the current Dell environment as well as their on-demand architecture.

Key Takeaways

• A more thorough understanding of Sauce Connect
• An understanding of Dell’s complex development environment
• A new way to use SauceConnect tunnels in a more complex environment
• The pitfalls we’ve encountered with our tunnel strategy

Bio
Morgan Vergara has been doing software development for 30+ years, most of it at Dell since 1992. They wrote their first line of code (FORTRAN, for the curious), in 1978 and never looked back.

How To Lie With Test Automation Metrics

Abstract
Phil Wells is a senior software engineer for the New York Times crosswords and games group. In this diabolical anti-talk, he will reveal the time-worn nasty secrets handed down through generations of test and QA professionals. Automation engineers love measuring things like code coverage, browser coverage, build time, and pass/fail rates for one very simple reason.

These stats can be cheated.

Ever the bad influence, Phil will lead a seminar in how to use these metrics to drive a practice that is solely for the purpose of beefing up those metrics. Real software testing, he will reason, is not about limiting rework or ensuring confidence in a team’s software delivery process. It’s about those numbers. It’s about validating the existence of the practice itself. More than anything else, it’s about looking out for number one.

Then, at the end, Phil will drop the pretense and talk about a couple of metrics that are actually fine and how we can measure those.

Key Takeaways

• Anti-patterns in designing and managing test automation projects, and better alternatives
• Effective (and ineffective) indicators that automation efforts are yielding positive results for your team
• How to trick your manager into thinking you’re doing a ton of work with the magic of statistics 😉

Bio
Phil Wells has been a software quality practitioner for over a decade. Now, Phil is a senior software engineer with the New York Times crosswords and games team. This team maintains the most popular crossword product in the world. Phil works to ensure that this team builds quality into every new feature and game they deliver.

What is the Mobile Automation Lifecycle?

Abstract
Mobile applications have transformed our workplace. As they become more and more ubiquitous, many employees tend to rely on their mobile devices and work-related applications to complete everyday tasks. Traditional manual mobile testing is no longer sufficient in the fast paced mobile development industry, therefore a systemized flow in mobile automation testing has become indispensable.
In this talk, Tony Zhang will cover the mobile automation lifecycle:

Phase 0. Inception (Locator enhancement with Devs)
Phase 1. Plan (Native vs. Cross-Platform frameworks)
Phase 2. Development (Mobile automation architecture)
Phase 3. Stabilization (Simulator/emulator, devices, cloud farms)
Phase 4. Deployment (CI/CD)
Phase 5. Maintenance (New API, deprecated service support)

Key Takeaways

• How SDET can play a role in project planning
• Which framework is the best fit to your organization
• What are the best practices of mobile automation architecture

Bio
Tony Zhang has worked in different roles in software development field as a quality, software and usability engineer. With a human-centered interaction background, he is passionate about bringing user research/design close to testing. Currently, he is a mobile automation advocate and Sr. Quality Engineer with Duo Security, providing successful mobile testing, and research through the innovative use of technology.