I’m keen to loop in older threads on this whole topic, but today I want to ask the question a little differently. I want to hear from people who have moved between these roles, but also from people who have never been programmers, or never been testers.
A recent online forum (shall remain nameless) posed the question, is test automation just easier than programming? A lot of people seemed to think it was, especially people who had become SDET after being a programmer. I wonder if the MOT community have a similar leaning. Many commenters tried to explain it based on pay-grade alone, which is perhaps an argument more about market-forces than how demanding it is to be the only tester in a team of between 5-12 engineers. Is being a tester more self-management skill heavy. Are release-test-executions deadlines worse for us than for developers?
I think it is easier. What I do know is that the last 19 years have been very liberating. I have worked in many embedded and a few desktop products that have given me chances to learn about an entire system vertically and horizontally and all the parts that go into it. Maybe not in deep detail, but dipping in wherever I choose to, and being more free. When a tool does not work I choose another or write one of my own, unlike developers who have investment and cannot just change languages or the tech-stack and toolchain in a matter of weeks. Sure it is frustrating at times, but tasks like CI/CD and defining processes are also on the table if that’s your bag. Flexibility in my mind is greater for automation testers.
I’ve worn both hats EXTENSIVELY. I was a hooby developer, then a tester, then doing development (non SDET) work along side my testing, SDET, to several years of development work where I was advocating for testing/quality. Pushing for testing as a task versus a role to the point where we didn’t have a dedicated tester. Lots of player coach stuff with development and testing practices.
Doing they both have their own challenges and how they intersect is very challenging when trying to deliver solutions. I don’t know if easier is a useful way to frame it. I think it’s more complex than that. Oh man, I can tell I haven’t given a tech talk in a while. I could feel the urge to stand up and talk with my hands.
I agree with @testingrequired that easier feels the wrong word, its different certainly.
When I was a developer I was very functional and not that creative. I enjoyed writing small tools to save time, not so much working on large products. When the dev technologies started to evolve, I’ll be honest I wasn’t that interested, front ends were needing to be more creative and it just wasn’t something I was good at or enjoyed. Like a lot of people, I got into testing by accident and the opportunity came at the right time as I was feeling out of place in development teams.
When I got into automation using the commercial tools like TestComplete or QuickTest Pro I loved it. It was like developing lots of little tools where I could see the benefit of my work quickly. It just fitted the way my brain worked.
I have tonnes of respect for creative devs working on large products with large teams. Yes we all code, but the difference is how you like to work and the type of output that brings you joy as a result.
It depends on what kind of operation you are running. As most here I guess are aware of. being a good tester does not entail being a good programmer. Managers love that idea but anyone interested in testing enough to read this will know that programming does not necessarily rock the boat of someone whose boat gets rocked by testing.
So I have seen, ever since my first testing/test leading era when the Berlin wall came tumbling down, testers struggling with automation. And I have seen incredibly complex automations done by someone hired as a consultant in an “test automation project” supposed to be used and maintained by testers.
Working for large organisations I have seen this working, when a separate test automation department maintains it, run by code brains.
In a small organisation now, I do a fair bit of API and Front end automation, not loving programming but still being a decent one, using AI, and I strive to make all automations straightforward and easily maintainable and understood. This is obviously “easier” than the production code done by the programmers. While some automations I have seen earlier (sometimes successfully maintained, sometimes not) have been well up to par with production codes.