Developers should not lead your automation efforts. I’ve never seen this succeed. In fact, many times I have been brought on to teams to clean up the mess that is left behind when developers try to lead this effort.
The reason is simple.
Tweet ThisI’ve seen managers, recruiters, and even thought leaders in the Test industry say “what we really need is a developer to get this automation strategy off the ground!” I cringe every time I hear it because I know it’s a recipe for disaster. I’ve seen the best, top-notch developers and architects fail at this! That’s because automation engineering is much more than just coding. The same rules and principles that apply to development don’t always apply to automation engineering. Trust me, I’ve worn both hats.
Yes, developers can code, but automation engineering is a discipline where coding is just one aspect of it. What about the rest of the art of automation engineering? You’d be hard pressed to find a developer who is studying and following the field of automation engineering, and who understands the delicacies of how a stable and robust automation framework should be built.
I’ve seen developers think “how hard can it be?” and end up throwing together a messy and unmanageable framework that eventually has to be totally refactored by a true automation engineer, or worse, scrapped altogether.
Now, I’m not saying that a developer cannot become an automation engineer, because I’ve personally converted quite a few who left development roles to work in test and have become amazing automation engineers. But quite a bit of training was needed. The key to getting this to work was that the developers made a conscious decision to transition into automation positions….meaning they were fully devoted to learning the craft and the skills needed beyond just coding. They weren’t developers who were forced to “get that automation thing going”.
So what are the traits and skills needed to lead an automation strategy? I’m glad you [finally] asked! Here’s my list…the items are not in any specific order
- a testing mindset
- programming skills
- ability to implement object oriented programming principles
- software architecture skills
- an in-depth understanding of automation concepts such:
- Page Object Model
- the inverted test pyramid
- test data management
- continuous integration
- the separation of tests and framework
- reporting and test tracking
- distributed/parallel testing
- test case management (volume, suites, stability, etc)
- helper/utility mechanisms for common tasks such as database access/querying, service layer access, etc
- awareness of automation anti-patterns
- awareness of different testing tools and techniques to be able to make best recommendations
This is not a comprehensive list, but you get the idea. As you can see, programming is just one of many skills required of an automation engineer, especially one who is tasked with leading an automation strategy. Do yourself and the entire team a favor and stop asking your developers who know nothing about automation to lead your efforts. Hire an automation engineer!
Really nice post with a good list of skills needed by automation engineer. I fully agree on the point that test automation activities should be lead by person who is fully dedicated and focused on the automation role and has the necessary skills to success on it. Based on my experience, as automation engineer you need to be focused on quality and testing, but have also interest on programming and tech. As automation engineer you need to master mixed set of skills from to tester, developer and devops roles.
Something I would also highlight (not mentioned in the article), is that automation should not either be lead by testers. By testers I mean “manual” testers who are not comfortable with programming and automation tools and frameworks. In these cases you can also very easily end-up with slowly progressing automation project full of unmanageable code, anti-patterns and lots of technical debt.
I have been saying this for years and agree wholeheartedly. Test Automation Engineering Leads/Managers should lead these efforts. We may be harder to find but we are out there and this is what we do.
I’ve not generally been a fan of the “SDET” or test automation engineer idea because too many companies think they can solve all of their development problems by hiring one. IME if the developers do not master good development practices that involve automation, such as TDD, you can automate all you want at higher levels but the code is still gonna stink.
That said, you make some excellent points and reading this has opened my mind on the subject. Last week I had a conversation with devs on my team and found that indeed they were not familiar with some common test automation anti-patterns. They’re top notch developers but they don’t have experience with things like good UI test automation patterns.
What has worked best for my teams in the past was testers and programmers collaborating on the test automation. Frameworks that promote collaboration, with testers specifying tests and programmers coding the fixture code to automate them, have helped make sure we all share understanding of each story and feature. But in my current team, we haven’t been able to really make that collaboration happen.
Thanks for the food for thought!
[…] test automation architects and engineers will be in high demand. In fact, most of the time having an automation engineer is preferred to a developer because testers have the mindset, training, and specialized skills for different automation tasks, […]