What value do we provide as testers? The short answer is that testing has no value in itself, testing is a service we provide to our teams so that our company can deliver value-adding products or services. Today, due in part to the evolution of development practices and in part due to the adoption of new technologies, engineers who used to “only” test can now expand their value towards Quality Engineering in the broader sense of the word. This is the goal of Modern Testing as explained by Alan Page and Brent Jensen: "To Accelerate the Achievement of Shippable Quality" In this talk, we will briefly review the forces pushing forward the changes in the way we create and deliver products today. We will introduce (for those who have not heard about them before) the Modern Testing Principles. And we will review them to understand their challenges and breakthroughs! Finally, we will review concrete ways in which we can apply these principles to our day-to-day work, starting tomorrow!

A test strategy brings teams together to establish a foundational set of principles to quality into their apps together. Teams, products, and applications vary, so how do we build a testing strategy tailored to meet your organization’s needs for a quality product? In this session, we will look a the role of automation within a test strategy. Brendan will provide heuristics to help guide in identifying what types of tests to automate and how many automated tests you will need. He’ll then investigate the personas: the creators, executors, and consumers of automation that can make or break your strategy. Finally, Brendan will share a model to guide teams in crafting and discussing their own test strategy that sets a foundation for quality, identify where an application needs support and determine the risk and management through the software development lifecycle.

In the era of DevOps and continuous deployment, more and more organizations are demanding a move from lengthy release cycles to shorter deployments - occurring weekly and sometimes even daily. To accomplish this, test automation is not only required, but is now an integral piece of the continuous integration pipeline. This is a vast contrast from how test automation was viewed not very long ago. In the past, teams treated test automation as a side project - a stepchild like Cinderella. But with its newly discovered importance, test automation is now the “belle of the ball”. So, how does this change how we develop test automation? In this talk, Niranjani will share her experiences driving test automation from rags to riches at companies such as Lyft and Pinterest. She’ll discuss the practices of building a team and culture to support test automation, as well as failures and mishaps that they endured. She’ll also share the lessons learned of how to prepare tests and infrastructure for this new and richer lifestyle of being a part of CI/CD. Join Niranjani on this magical journey to transform your test automation from rags to riches. You’ll learn how to dress up your test automation with design patterns that improve CI efficiency, and embark on a whimsical coach ride by wrapping your tests in containers to simplify your build process.

The widespread adoption of test automation has led to numerous challenges that range from development lifecycle integration to simple scripting strategy. Just because a scenario CAN be automated does not mean it SHOULD be automated. Teams that adopt automation often rush to automate everything they can -- the automation firehose. For those scenarios that should be automated, every team must adopt an implementation plan to ensure value is derived from reliable automated test execution. In this session, the audience will learn how to automate both strategically and tactically to maximize the benefits of automation. Entry criteria will be demonstrated for automation in the development lifecycle along with a set of checks to determine automation feasibility & ROI.

If a product works but your users struggle to complete a task due to poor performance, does it really work? Performance and load testing is a task that is often overlooked in the drive to deliver better software, faster. It is also a task that is little understood by the business side of the house. Through experimentation and interviews with business partners, Adam has identified key factors that will help your performance testing land a place in your DevOps pipeline as well as provide a meaningful impact to your business.

In an effort to implement the latest and greatest QA best practices, teams can sometimes rush into a non-viable solution, wasting valuable time and effort. When a team doesn’t fully understand the problem, you’ll never reach your desired solution. To be seen as problem solvers, we have to focus on achieving outcomes for problems in a smart way. In this presentation, Margaret will discuss the importance of spending more time in the problem space, rather than rushing into a solution. Your solution needs to be measurable and demonstrable to management and show value to your customers, otherwise, what’s the point?

Roughly speaking, ‘fuzzing’ is testing without an oracle, i.e. testing without knowing what a specific outcome should be. When fuzzing, we don’t necessarily know what should happen, but we have a good idea of some things that shouldn’t happen, such as 404 errors and server or application crashes. We generally apply fuzzing to help uncover these kinds of errors when we’re testing text boxes, but why should textboxes have all the fun? Websites created today are highly interconnected, multi-server applications that include connections to out-of-network servers that are controlled by neither the applications nor the team. This situation makes it difficult to both enumerate and control all the possible combinations of paths through our system. Even if we could identify all the possible paths, most organizations would not have the time to test all these scenarios, regardless of whether they apply automation to help with that testing. During this session, we explore how expanding our automation approach by using randomization can help mitigate the risks associated with hard-to-enumerate application scenarios. By using random clicking, we can provide testers with additional information via exploring paths through the application which are not intuitive, but which are still valid. We’ll discuss why creating a random clicker doesn’t have to take a lot of effort, how this approach is rooted in the facets of High Volume Automated Testing (HiVAT), and some considerations of which to be mindful when using randomization.

You can’t depend on flaky friends, so why count on your flaky scripts? Seemingly at random, a test will produce different results, go from a pass to fail, or refuse to run altogether. Just like those friends who can’t be relied on, flaky scripts fail to fully meet your expectations. After spending countless mornings troubleshooting the failures, you eventually retire these scripts to the trash heap section of your To-Do List. In a recent Kobiton survey, almost a quarter of respondents listed “The need to continually update test scripts” as the biggest negative surprise on their journey to automation. This problem is exacerbated in the mobile app world where your test script may work on one device yet fail on another. Join Frank Moyer as he discusses the true impact of running flaky test scripts and ways to minimize and identify broken scripts. What you will learn: - What are the best metrics to use to capture the cost of flaky scripts? - Do organizations measure this cost? And what needs to be in place to capture measurements? - What causes flakiness and why is it even worse in the mobile world? - Is it possible to live in a world without flaky test scripts?

Focusing on more valuable automation, shifting traditional “right” tasks left, and tailoring refinement to account for more efficient activities are some of the topics we’ll discuss. You’ll take away practical outcomes that will be relevant no matter where you are in your DevOps implementation. The role of QA/QE tends to be ambiguous within Agile teams who are pursuing the DevOps approach within their SDLC. There are many misconceptions around QE’s role, automation, and which agile ceremonies make sense in DevOps. Melissa will share her insight on how she consults with companies – from startups to Fortune 100 companies – on the innovative ways QA/QE can add value to DevOps by focusing on efficient tasks. Key takeaways include: Defining the QE Role Re-tuning Automation Shifting traditional QA/QE “right” tasks left Re-defining Refining Shippable By deep-diving into each topic, you’ll get innovative ways to leverage Agile and QA/QE activities to ensure a consistent, efficient, and productive playbook for DevOps.

DevOps focuses on three things; People, Process and Technology. But what happens when you try to implement change in the wrong order? The pipeline breaks down and comes to a halt. This session focuses on the aspects of the release pipeline beyond continuous integration. We'll be covering how to handle test automation (flaky tests, manual testing, lack of testing), Waterfall Methodologies, manual gates, incident remediation, and of course, the audit team. This session will touch on how to approach these topics from the ground up and implement transformation while handling the typical objections to change.