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?
Whose Decision?
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.
You made some great points Paul! That said, some of the teams and companies I’ve seen do value new features and have this mindset of throwing multiple things over to the user to see what sticks. They only care about ‘quality’ peripherally. While they throw around slogans like ‘everybody is responsible for quality’, ‘everybody is a tester’, at the bottom of the heart they only believe in experimenting, quickly iterating, fixing only blocker/critical bugs. In US hightech industries that seems to how the market works: from facebooks fail fast, fail often; ubers self driving car ‘experiments’, msft elimination of tester role etc. I am not saying its the right way to engineer things but that’s how the companies are operating. Tell me how many startup companies have a tester/automation guy in their first 10 hires? I am a career SDET and I really hope that test automation is not seen like a fly over job but it is very hard for me convince a junior dev to switch to an SDET because carer trajectory/salary comparision doesn’t look good.
Satyajit – As you alluded to, companies are as nuanced as individuals. Some care greatly about quality and some less so. I love that the marketplace can help drive those decisions and some methodologies (when applied adequately) can help marketplace feedback push quality to the forefront. I’m like you, though. I like high-quality applications. I’ve had to learn from my clients that “acceptable quality” is a sliding scale and we have to assess “what is the level of risk we’re willing to accept?”. Thanks so much for reading and for your well-thought-out comment!
You make a good case for having people on the team whose main job is to automate tests and testing-related infrastructure.
Until my current job, test automation was always a part of my job and I did it well. I have a programming background and I’m reasonably competent at writing maintainable test code, setting up the CI to run tests, and that sort of thing.
A few years ago, a keynote by Gojko Adzic persuaded me that maybe I shouldn’t cling to trying to do test automation on my own. He made the point that the programmers who write production code are really good at writing code. Testers are really good at specifying tests. So it makes more sense for testers and programmers to collaborate to do the automation.
IME the huge benefit to this is that when we have to work together to automate our executable specifications while we are working on a new story, we have to come to a common shared understanding of how that feature or piece of feature should work. (And we probably have to get with business experts, designers and others to have that conversation).
My last team used (well, they still use, I’m just not there anymore) FitNesse to automate tests at the API level. Usually one of us testers would write a happy path test for the story, then the dev or dev pair would write the fixture code to automate that test and make it pass. Then we testers (though sometimes it was a developer, we always had more testing to do than we had testers) wrote more test cases and pumped more scenarios to the production code until we were satisfied the code was done. If you asked anyone who I worked with on that team why they liked FitNesse, they’d tell you it was because it forced testers and programmers to talk to each other.
So this statement disturbs me: “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?” I think that would be bad. We need to be collaborating with all these people. I think it is much better to build quality into the code from the start, not try to somehow insert it through post-development testing.
All that said – I know some awesome people who consider themselves testers first, but who love to write code and do great test automation, and I have known great teams of test automators. As you point out, they’re fairly rare. I wish I was one of those people! I do think this is a good thing to have in some contexts. I just would prefer, in most cases, for testers, developers, operations folk, and everyone else who is needed to collaborate on delivering value to the business frequently, at a sustainable pace, supported with useful automation.
I run into a lot of test managers who are trying to hire SDETs because they think that will solve their quality problems. When I start asking them questions, I usually learn that the developers are doing NO AUTOMATED UNIT TESTS, and even worse, they often have no CI. I do not believe an SDET is going to help that situation. They’d be building automation on a foundation of weak code.
Lisa, thanks so much for the comment. I think that statement could be read as “What if your team _never_ had to ask for help from dev or ops? What if your people could independently make the code base more testable _and never work with others_?” But that’s not what I intended. I was trying to show an option, a possibility rather than state a rule. Seeing how you’re reading it, I realize it probably deserves some clarity.
I believe strongly in a “one team, one effort” mentality. That team stretches from dev to test to marketing to sales to all corners of the effort to build the product. Having the ability to work independently doesn’t require we do it all the time, but can be incredibly helpful at the right times. Teamwork is extremely important in organizations and one important key in building products together in a knowledge-worker-based industry like software.
Btw, folks, if you don’t know who Lisa is, go look her up and buy her books. Lisa, thanks so much for sharpening my writing! Your comments add so much color and texture to this conversation!
🙂 Thanks for clarifying. And for your kind words!
@Paul@Lisa Thank you for making those great points. In my recent years I was lucky enough to meet a few test engineers that converted from lead software developer role or software architect role to lead test engineer. Also met a fellow test engineer who was pretty much working in a full devops capacity as well contributing greatly to the test framework. I was amazed in his depth of knowledge in devops, cloud services as well as his passion for testing. Knowing a bit better I found out that they have decided to be test engineers by choice and have quiet the passion for test and automation. It is wonderful to meet people as such and is an indication that a bright future lays ahead for test engineers. I have been out of educational institution for a while. I hope schools, universities promote test engineering at the same grade as of software engineering.
[…] One of my goals is to push the discipline of test automation forward. To do this, I like to help test automation engineers grow. I look forward to the day when test automation engineers have all the background and skills of developers and are similarly respect…. […]