Saturday , February 24 2018
Home / Agile Software Development / Why Converting Test Teams to Automation Is a Challenge

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:

About John Friscia

John Friscia was the Editor of Computer Aid's Accelerating IT Success from 2015 through 2018. He began working for Computer Aid, Inc. in 2013 and grew in every possible way in his time there. John graduated summa cum laude from Shippensburg University with a B.A. in English.

Check Also

Metrics That Are Destructive to Agile

Key performance indicators (KPIs) play a critical role in business strategy, but are they unwelcome …

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?

Leave a Reply

Your email address will not be published. Required fields are marked *

Sorry, but this content
is for our subscribers only!

But subscribing to ACCELERATING IT SUCCESS is FREE and only one click away!
Join more than 40,000 IT Professionals and get the best IT management articles to your mailbox with Accelerating IT Success!

Unsubscribe at any time