Are Test Automation Engineers who are better coders in the wrong place?
After posting “7 Ways to Better Automation”. I received the following question about Test Automation Engineers who are better coders:
If your tester can write test code better than product code that’s catch-all-error, more robust and consistent, I think he’s in the wrong place… Shouldn’t he be helping at creating the product itself?
What do you think?
I don’t know the person who posted this question. To be fair, I don’t know the details of where he’s coming from. Who knows, there could be a lot of things going on behind this question. But let’s dig in anyway. Are Test Automation Engineers who are better coders in the wrong place?
If a person decides to work in testing with automation, that’s his or her decision. Who is anyone else to tell them that they’re “in the wrong place”? While the role of the manual tester is crucial, the software industry needs more testers with rich technical backgrounds. We need testers steeped in code, automation, and deep technical knowledge across stacks, platforms, and applications. Testing is getting more difficult and the surface area is greater than ever. We need more testing. Coding is one way a tester can have exponentially more interaction with an application under test in order to learn what it does.
Testers that can code as well or better than software engineers are rare.
I know they’re rare, I’m constantly trying to hire them. One of these people with exceptional software engineering skills working as a tester can magnify what an entire test team does. She can extend the team’s reach far beyond what it would have been otherwise. Imagine what being able to set up a build script, a test environment, integration tests, or install static analysis tools in your environment would do for your test team? What if your team didn’t have to ask for help from dev or ops? What if your people could independently make the code base more testable?
Most of the time I see test teams subjected to the whims, wants, and “whenevers” of developers. (By the way, I love developers and mean no ill-will, but couldn’t resist the alliteration.) Having someone like this on your team empowers it. No more waiting. Move ahead — with haste!
What are our Values?
There seems to be an embedded set of values in this question, namely that development of the application is more valuable than testing it. Haven’t we seen the results of this? How many teams work in an “agile” environment, but can’t test within their sprint? How many companies are losing users over applications that don’t work? Many times this comes down to one issue: values. The team values new features more than it values features actually working. Does it make sense to value construction of non-working code over working code?
Until testing is persisted in the form of executables for each feature, we can’t regression test each deliverable fast enough to compete in a digitally transformed world.
Which code should be better?
Shouldn’t the code that catches issues be better than production code? How else will it catch bugs? If test code has more bugs than production code, is it untrustworthy? If we can’t trust test code, it hinders us in creating working code. How does bad test code affect us? Can we produce software with high quality?
A Flyover Role
I hope that one day test automation becomes a destination job, rather than a “fly over” position on the way to developer. I hope test automation engineers who are better at creating software than developers become the rule, rather than the exception. Test automation is a fun, challenging, and exciting role. If this role is yours already, join me and let’s take it to the next level together!
Are you ready to get started up-skilling your testers? Do you need a test automation boost? Contact us now.
Credit: Photo by iDriss Fettoul used with permission from Unsplash.