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.
As per my pov, I don’t believe the comparison is correct, because programmers code from a business perspective primarily, while testers write scripts from a testing perspective with end-user centric. Both require critical thinking to write the logic, but their end goals are different: for developers, the end goal is to meet business requirements, while for testers, the goal is to enhance the user experience.
Sometimes both get stuck, and sometimes both easily solve the problem, it depends on the complexity and understanding of the modules. At the end of day, both are doing similar jobs but notthe same. The nature of the job may be the same, but not the thinking.
Ha ha. I’m not a talk-giver person, I know loads of the talk, but it’s not in me. But I know how you feel. That’s why I asked this question, to get an idea of whether the people active in this community, whom I highly respect, are on the fence like me too.
I too have never been a front-end person. I wrote device-drivers for 18 years, one dialog-box for settings was all the front-end I could handle thank-you. I slipped into QA, when I moved continents and it was mainly because it was just a lower job-barrier to get over, and perhaps, my confidence as a coder on a brand new application after 14 years on one app, was just not there. My first test engine was google robot. Did not last long, but it inspired me to write my own tools.
I’m fully with you, testing does require a kind of long-term vision, only because tests continuously break just due to the dynamic environments that software lives, and how it changes so often. So something that is easy to keep running, ends up being a balance to keep it as simple and maintainable as possible in case you leave one day, but still good at catching regressions with minimal false positives.
I have worked in a company where a “brains” team did all the QA, and it was a bit of a “clique” organisation structure as a result, not a fan. So yeah, being a QA might be more about politics than if you are just coding. But I’ve also had a lot of politics as a coder too.