We firmly believe that automated testing puts the "A" in "Agile". Without an effective suite of automated tests your ability to be truly agile (that is embrace change) can only be based on the hope that your latest change doesn't have unintended consequences. Additionally, without automated tests, you are missing a vital component in getting feedback into the development team's hands. In our travels, we have encountered many organizations that are struggling with automated testing. These organizations are successfully adopting many Agile techniques but are failing when it comes to automated testing. We frequently hear "Automated testing just doesn't work for us" (eerily reminiscent of the days when we would hear, "Agile just doesn't work for us"). From our experience addressing their challenges, we have identified anti-patterns common across these organizations. These anti-patterns look like they should work, but are in fact doing more harm than good.

This talk is about those anti-patterns. We have given those anti-patterns a name and a face to help organizations understand why they are not getting the benefits from automated testing that others are. We describe several anti-patterns, such as the "Ice Cream Cone", the "Monolith", the "Sunk Cost". We explain why these anti-patterns appear to be good solutions, what makes them attractive, and why they do more harm than good. We talk about the right approach and draw on our experiences helping organizations adopt a robust automated testing strategy that instills confidence and provides fast feedback to the development team. We explain what benefits from automated testing the anti-pattern is preventing. 

“Running a football team is no different than running any other kind of organization…” -- Vince Lombardi

Large enterprise scale software development is a team sport. In order to win in this game your software needs to be of the highest quality, which is almost impossible to achieve with testers on the sidelines. To build a winning a team you need the right players, but great teams don't always need the best players. Great teams win because they find ways to let the individuals on their team be great. 

The wave of DevOps in the industry is in a broader sense an effort to let developers and system engineers do what they do best by eliminating or simplifying tasks that forced individuals into activities beyond their expertise. Pre-DevOps roles were like trying to ask Payton Manning to play both quarterback and running back at the same time. DevOps is the manifestation of empathy between two distinct sets of skills allowing the other to focus on what their best at. What about testers? How can the team expand their empathy to their role? What can the developers, program managers, and others do to let testers be great? Please join me if your curious to hear about the practices, tools, and culture that can make your software a winner with quality.