Your Tests Aren't Flaky, You Are! with Richard Bradshaw

After a bit of a hiatus, I'm glad to say we have a meetup lined up! And it's with great delight that I can share Richard Bradshaw is joining us in the great Puppet (https://puppet.com/) office, with additional sponsorship from the wonderful folks at Sauce Labs (https://saucelabs.com) and Bazaar Voice (http://www.bazaarvoice.com/).

Richard Bradshaw is an experienced tester, consultant and generally a friendly guy. He shares his passion for testing through consulting, training and giving presentation on a variety of topics related to testing. He is a fan of automation that supports testing. With over 11 years testing experience, he has a lot of insights into the world of testing and software development. Richard is a very active member of the testing community, and is currently the FriendlyBoss at The Ministry of Testing. Richard blogs at http://thefriendlytester.co.uk and tweets as @FriendlyTester (https://twitter.com/FriendlyTester). He is also the creator of the YouTube channel, Whiteboard Testing. He works for Friendly Testing, a provider of consultancy and training within testing. He can often be found in the bar, with a beer in hand, discussing testing

Abstract:

Your Tests Aren't Flaky, You Are!

Flaky this, flaky that, the only things I like flaky are my puff pastry and a Cadbury’s Flake.

However, a week doesn’t go by without seeing some activity in the community on the subject of flaky automated checks. Most recently was this lengthy post (https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html), with masses of analysis by a team at Google on where they believe their flaky checks come from. Some useful insights in there, mostly around the size of the check and the tools used. However, I feel they missed the all important part, you, me! the person who actually created the automated check in the first place. All flaky automated checks come from us.

Automated checks have become an essential part of most teams approach to testing, and trying to build a quality product. They’re important for many many reasons, we’ll discuss though during the talk. But, it’s important to remember where these checks come from, they come from us. More specifically from the knowledge we have on the tools being used and most importantly our applications and their architectures.

I view automated checks as algorithms. Algorithms that are designed and implemented by us. Two important parts there to avoid flakiness in the final automated check. The design and the implementation. I feel far too much effort and focus in on the implementation, and we all know what happens if you implement bad design right?

In this talk I intend to break down the process of designing and implementing automated checks, going deep into the areas that I believe are critical to creating automation that returns real value to the team, checks that aren’t flaky, checks that don’t result in some poor person continuously playing the role of broken flaky automated check fixer! I’ve played that role, it sucks!

Takeaways

- An appreciation of the skills required to design good automated checks

- An appreciation of the skills required to implement a good automated check

- How these skills differ, and how the whole team need to be involved

- The importance of continuously reviewing our automated checks for implementation, risks and value added.