Welcome to another episode of Automation Explanation, an Agile Thought Podcast, where you will learn about quality through automated testing and its place in modern software development.

This week, your hosts, Antwan Maddox and Greg Burdick, are exploring the myths in regard to the role of Test Automation Engineers. Nowadays, there is more collaboration than ever before in the automation arena and most is happening remotely; the challenge is to provide a high-quality customer experience. People are investing a lot in automation, but it is very unlikely that they are actually succeeding in it, resulting in the failure of most automation processes, and the root cause often begins with wrong perceptions about the engineering role. Today, Antwan and Greg do their part to stop perpetuating these Automation myths.

Key Takeaways

• Automation Engineers/QE/SDET are not magicians.
• • The origins of the magician myth: No Automation Engineer can take care of everything, meaning the automation performance, low testing, data validation, and mobile testing. There is no single person who has the breadth and the experience to the depth to be able to succeed in all these areas.
  • Myth: Automation will solve all your problems. Automation cannot replace manual testing or solve communication bottlenecks as well as other problems that are related to the overall organization.
  • Myth: Let’s automate 100% of the test cases. Why do you have manual testers in the first place?
  • What is the intention behind using commercial tools? If the intention is to put a bandage around the lack of mature collaboration among the Teams utilizing Automation, it is wrong. Automation is better suited for Agile Development Teams that understand the mature process of leveraging automation.
  • There often isn’t a proper ratio between Developers and Automation Engineers. Without an appropriate scale, you can’t expect positive results.
  • Myth: Automation will eradicate all bugs and defects. Test Automation encourages repeatable testing and it happens to find bugs, but this is not the central point of Test Automation.
• Why do these myths even persist?
• • Organizations look for an Automation Superhero as a result of Agile immaturity which is still a challenge for many organizations.
  • The inertia of dysfunction and resistance to change are two of the reasons why these myths persist.
  • The perception that testers are cheap also contributes to these myths remaining.
  • Some organizations expect Automation Engineers to accommodate their dysfunction and not challenge it.
  • Lack of education in regard to Test Automation motivates these myths to stick. Antwan talks about the criteria for continuing testing maturity which fall into five categories:

1. They do not have enough foundation to support the appropriate level for continuing assessment.
2. Testing is an afterthought but test automation is at the forefront (which is so unbalanced from the Development Teams perspective!).
3. There is nothing on the frontend that supports automation.
4. There is little to nothing on the backend that supports animation. Do they even know what the Automation Team needs are?
5. The movement toward change is scary and delays progress.

• What can we do to move forward?
• • Empathy among Teams in providing what is necessary; empathy can be a game-changer!
  • Understanding the architecture around the application.
  • Assessing your level of maturity as a Team and as an organization towards Automation.
  • You can have better quality with fewer tests.
  • Setting up the environment for collaboration.
• Antwan shares some real cases to exemplify how to tackle these myths in organizations.

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!