Agile Software Development

Why Converting Test Teams to Automation Is a Challenge

Can all testers transition to become automation engineers? Maybe, but will you actually see it happen in your organization? Test automation consultant Paul Merrill would bet against it. In an article at TechBeacon, he explains the nature of the challenge and what you may have to do if you really want to go fully automated with testing.

Automation Can’t Be Automated

As Merrill explains it, Google and the like only use software development engineers in test (SDETs) for testing, but they did not achieve that state through lengthy transitions. Rather, in typical Google fashion, they just sought out and bought people who were already outstanding automation engineers. Not every business has this luxury.

You only have your currently existing team of testers, some of whom may have limited coding experience, and some of whom may actually just be not very good at coding. If such people are allowed to write code for the business, they may up end creating more problems than they solve when they introduce new bugs and technical debt. So where does that leave you then? Between a rock and a hard place:

For [transition] strategies, creating blue-sky projections is easy. You just assume that new test automation efforts will bring a return on the time invested in training. But that’s not going to happen. It is difficult enough for most groups to create test automation for new features, much less for existing regression test suites.

Either you have to hire more testers to do your existing testing, or you choose not to do some of the testing. But if the problem was that you weren’t getting enough testing out of your testers to begin with, you’ll get even less testing out of them as they pursue this path. The effort will increase your payroll and training expenses while slowing down product delivery.

To make the best of a rough situation, you have to strive for more realistic expectations and objectives. You should also assess testers’ skills and their job motivations, to determine which ones really are suited to transition into becoming automation engineers.

You can view the original article here:

Show More

One Comment

  1. But is a high-powered, “SDET-only” automation engineering staff truly required for ongoing testing operations?
    That is, can the launch of an enhanced testing program also have room for the rollout of tools and protocols to reduce the need for automation engineering as an ongoing part of testing?
    A difference can exist between engineering automated tests and executing the work defined in an automated testing program. Perhaps a well-developed (automated) testing program by design is amenable to various tester skill sets.
    After all, why pursue test automation if not to optimize longer term testing efforts?

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.