Accelerating Your Digital Agenda with Continuous Testing

As organizations accelerate their digital agendas and become obsessed about delivering a flawless customer experience, application development and delivery teams are under pressure to move faster than ever. This increasing emphasis on speed and quality has put testing in the eye of the Agile+DevOps hurricane, and made continuous testing critical to business success. What does continuous testing mean for testers, developers and business users? How are enterprise organizations adopting and adapting for quality at great speed? In this keynote, Forrester analyst Diego Lo Giudice will shed light on the trends and practices poised to shape the testing market in 2019 and beyond.

Bio
With Forrester since July 2005, Diego primarily contributes to and advises on Forrester’s offerings for Application Development & Delivery Professionals. He partners with Forrester’s global application leaders and is a leading expert on SDLC processes and practices, covering topics such as Agile development, Agile and Lean transformations, Agile development sourcing strategies and services, Agile testing practices and tools, DevOps, and software testing and quality, with a key focus on systems of engagement. Diego also covers software delivery metrics, artificial intelligence, and open source governance.

His 28 years of industry experience, in addition to application development, allow him to give expert advice on change management programs for optimizing the overall modern application delivery process, execute technology management assessments, review technology management strategies, and make comparisons. He also has experience in complex mission-critical project and client engagement management.

What’s that Smell? Tidying Up Our Test Code

Abstract
We are often reminded by those experienced in writing test automation that code is code. The sentiment being conveyed is that test code should be written with the same care and rigor with which production code is written.

However, many people who write test code may not have experience writing production code, so it’s not exactly clear what is meant by this sentiment. And even those who write production code find that there are unique design patterns and code smells that are specific to test code in which they are not aware.

Given a smelly test automation code base which is littered with several bad coding practices, we will walk through each of the smells and discuss why it is considered a violation and demonstrate a cleaner approach by refactoring the code live on stage.

Key takeaways include how to:

• Identify code smells within test code
• Understand the reasons why an approach is considered problematic
• Implement clean coding practices within test automation

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.

Pyramids Are Ancient – Let’s Talk Automation Strategy

Abstract
‘Richard, what tests should I automate?’ ‘What should I be automating?’ ‘What layer should I be automating on?’ ‘Where do I start with automation Richard?’ These are questions I get asked regularly. My answer every single time? ‘Checkout The Test Automation Pyramid!’, ha, of course, it’s not, it’s ‘It depends…’ That’s because there isn’t a single correct answer to any of those questions, although most are looking for one. It certainly isn’t a picture of a triangle.

However, there are steps we can take, questions we should be asking, which will lead to answers. They won’t be the right answers, but they will be enough to progress, while we learn more and continuously adapt. These questions will allow you to map out your context, arguably the most important action to maximise your automation efforts. Knowing when to ask these questions, how to progress after the answers and who to involve are the most underrated skills in automation. You can learn all the programming languages, all the frameworks and tools, but if you don’t know how to audit your own context and frame your problems, they are irrelevant.

In this talk, I’m going to share the questions I ask in order to understand the context I’m in, allowing me to create an automation strategy. We’ll then compare those questions and answers to existing models highlighting the flaws in them, but also where they can provide some direction.

Takeaways:

• Understanding the importance of having an automation strategy
• A set of questions to help you understand any context and formulate an automation strategy
• How to evaluate and challenge existing automation models

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, blogs at https://automationintesting.com

Building Automation Engineers From Scratch

Abstract
Creating automation engineers from manual testers is hard. Even if testers are willing, they have a lot of hurdles to get over to feel like the same kind of subject matter experts in automation as they are in manual testing.

As a career-long manual tester making the leap to automation, Jenny Bramble has experience to explain frustrations and provide solutions. She will discuss managing the expectations of  testers and their managers (what’s the time frame? Why isn’t this working?), techniques for teaching (such as games! Pair/mob programming! Software fundamentals!), and how to know when testers have made it (what should manual testers be aiming for when they start?).

You’ll walk away from this talk with a powerful new set of tools in your toolbox:

• The basic framework your manual testers need to be successful—including how to determine where the gaps in knowledge are and filling them.
• Advice on managing the expectations of your testers and management from time constraints to what success looks like.
• Several methods for teaching framed around a case study of a team that built itself up from the inside out and is running a successful automation suite.
• Facing and overcoming other challenges such as ability and perceived ability, resources, time, tooling, and how to get your team excited for a new chapter in their professional development.

Bio
Jenny Bramble came up through support and DevOps, cutting her teeth on that interesting role that acts as the ‘translator’ between customer requests from support and the development team. Her love of support and the human side of problems lets her find a sweet spot between empathy for the user and empathy for the team. She’s done testing, support, or human interfacing for most of her career and is excited about the future of automation.

Page Objects: You’re Doing It Wrong

Abstract
Page Objects are the most commonly used abstraction pattern for functional UI Tests. They have the ability to enable users with little Selenium knowledge to write sophisticated tests against an application at scale, while reducing the maintenance costs as the application changes. Based on Sauce Labs Solution Architect code reviews, though, it is one of the most poorly understood and abused tools in a team’s framework. As an SDET at 5 companies before joining Sauce Labs, I’ve tried a number of different approaches and know first-hand what works well and what can cause problems. Experienced people will have disagreements with many of the points I will outline, and I will present both sides along with the reasons for my preferences.

The following principles (and more) will be discussed:

1. Imperative vs. Declarative
2. Page Object Alternatives
3. Deterministic vs. Non-Deterministic
4. Coupling vs. Decoupling
5. Inheritance vs. Composition

Bio
Titus Fortner is a core contributor to the Selenium project and the maintainer of the Ruby bindings. He spends a significant amount of time writing open source testing software built on top of Selenium. He is the project lead for Watir and is active in supporting these projects on Stack Overflow, message boards and in the Selenium Slack and irc. Titus has implemented automated tests at five different companies and currently works at Sauce Labs as a Solution Architect, working with the community to facilitate testing best practices.

Coming Soon