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.
I’m going to lean on a word you used - “liberating” - more than “easier” as a descriptor. I didn’t go to school for computer science and all my youthful experience was GNU/Linux-based. I entered the software industry with a large skillset that was a bit of everything, from sysadmin to programmer and from network engineer to tech writer. My first “real” tech job in 2000 was QA in a MS Windows shop start-up and the automation tools were Segue’s SilkTest and SilkPerformer. I think I generated and wrote more lines of code than the dev team automating all the scenarios we could come up with to test the application before GoLive. And it was fun!
From then to now I’ve learned to create small tools to help me no matter what the AUT/SUT is and regardless the commercial toolset being used. One of the great joys of automation testing is the creativity. Sure, it can get a little dry writing straight functional test scenarios but the process of automating them can be as infuriating as programming (same process: code->execute->debug->repeat) and as exhilarating (it actually worked this time!) Negative testing, experiential testing and the occasional vulnerability testing just add spice to the sauce. It’s liberating because, as noted previously on this thread, I can switch up my tools as needed to achieve the outcome.
Case in point, I use Keysight’s Eggplant Functional for automation testing now. Not so different from the Segue tools I used all those years ago. However, using Eggplant on Mac OS and Ubuntu Linux, I have access to many “helpers” I didn’t have back in the day, and Eggplant is open to almost all of them in terms of working happily together. I’m writing Emacs Lisp scripts to do everything from SenseTalk code editing to execution of Eggplant Functional on a remote SUT via their Eggdrive feature.
I think, like in every industry, partner streams like DEV/QA are similar yet different and there’s something for everyone. As I said, I started in QA professionally so the programming aspect for me was always test-driven (I even write tests for my own code) so I don’t have the concept of being a programmer, but I can see the level of liberation I have compared to some coders I work with. Our security engineers have that same vibe; bursting with creativity, always trying new languages and tools out, and they never seem to be bored. That’s the feeling I get when automating tests. I’m never bored. I use everything I’ve got to offer in the process. Liberated!
I’m going to mark this as an accepted answer, not because it’s right, but because it’s one of the answers that chimes with me. Thank you @chrisbryant .
As a Programmer-turned-tester, it’s this insight into my own frustration and my own joy as well. My latest job has me writing just as many “tools” as tests, so that element of having to test you own work comes into it too. As well as being free or liberated and able to shift to anything that needs more work and to use any script or any compiled language or tool as suits the task. Constantly moving, constantly chasing bugs, constantly finding new places they hide and flushing them out.
I do love this job! I won’t pretend there aren’t also frustrating moments, and it sounds like you understand that as well. I will say it’s all worth it, though. Glad it resonated, @conrad.braam
This is an important distinction. Coming from a Healthcare shop (20 years, now) I am always hyper-sensitive to the experience of patients when they use our software. I do think the original question comes from a more technical than deliverable perspective, but you are absolutely right to point that out! I will happily admit that much of my satisfaction come from being both a Quality “firewall” between patients and software releases, and also a satisfied user of the very software I test
I think it’s worth noting here that programming for a product that will be used by end users has a far higher bar for “good enough” than working on test automation frameworks. In a CI/CD pipeline, the test automation side can get on with its job while containing all manner of less-than-stellar coding practices. I should know - I’m correcting a couple in my own code right now, because it’s a good time to do so. Why do I seem so slapdash about it? I prioritised progress over perfection.
Working on a user-facing application, you need to think of everything. Then the tester needs to think of everything, in case you’ve missed something. With test automation, it boils down to the software running at all when asked to do so, actually doing the tests, actually failing tests (because we like to know our software isn’t passing tests in error), doing the number of tests required in the available time, and producing readable reporting and logging. Oh, and of course, doing it repeatedly.
I have to agree, when you are the solo QA or even overstretched QA, that’s when “running” tests totally trump passing tests. In the long run it is far easier to get running tests to pass, than to get non-running tests to provide you with any knowledge about a product.
I call down-time on my work every so often just to do refactoring and large low-level and high-level clean-ups when the framework code gets too hard to maintain. Every time I find it speeds up my work, a but like sharpening the axe often.
