The State of Software Testing Survey: Automation

Test automation is a vast topic. There are so many different areas to talk about: tool choice, jump-start, cross platform, services, cloud…Each of these areas have changed so much recently that they could each earn their own blog series.

From same sprint Test Automation in agile, to Selenium as a universal browser test tool, to service testing using containers in DevOps—so has Test Automation in itself.

At the same time, I am noticing a new trend that has not been as obvious, or as striking in the past. It’s the phenomenon of the ‘have’ and ‘have nots’! That is, those who have significant Test Automation programs and those who do not.

Some organizations have become quite sophisticated in their automation--there are companies today where the Test Automation software development project is nearly as complex as the production code project. Juxtaposed, some organizations struggle with the basics and most organizations fall somewhere in-between. From the first survey we did this past spring, we found there was a large amount of companies that function without Test Automation.

At the same time, despite landscape changes, one thing remains constant—the pressure to go faster, do more with less, and automate more.

Knowing this, we set out to look at this in our 3rd survey in our State of Software Testing Survey Series. The third survey’s results focus on test automation and take a full 360° view of the landscape to identify issues. The goal of this third survey covers skills, tools, benefits, and problem areas of test automation that businesses are experiencing right now.

One of the key findings of the third survey included a range of answers to the question “What would prevent you from automating more tests?” Almost one-third of the respondents are experiencing classic test automation issues. One problem commonly cited among respondents was that management didn’t fully understand what is needed to have a successful automation program; this included everything from process/team frustration, to tool choice.

One survey taker said: “In an earlier job, decisions about what automation tools were to be used were made by management, leading to a churn of new tools about every two years. When the automation engineers (my team) were finally allowed input, the selected tool was successful and was in place for at least 10 years, long after I had left the company. Lesson: Let the people using the tool choose the tool.”

A critical task when optimizing your test automation suite, or beginning to build a test automation program, is recognizing the issues. If you are in this boat—this is where LogiGear Magazine can help. Our latest issue of LogiGear Magazine focuses on all things Automation and can help you recognize areas you can improve on in your existing practice.