Reflections Of An Ex-Software Developer

Someone once told me, “QA Engineers are just Software Developers who aren't smart enough to code.”

And another, “Testing? Anyone can do that, that’s just repeatedly running tests here and there. That’s completely boring.” While applying for a new job, I found several companies with job descriptions like "No Tech Experience OK. You can start as a tester before working your way up to become a developer."

So when people asked me, years down the road if I wanted to go back to coding, (i.e., “You have quite some knowledge of Software Development. Don’t you want to go back to being a Software Developer instead?”) despite having more than 3 years of experience as a QA Engineer, I just try to suppress a sigh.

“I like doing QA work.” Comes the response. Somehow, the more I said it, the more it rang true to my ears.

“Really?” A look of disbelief passes over their face as if to say, "Well who would ever enjoy a QA job?" The stigma stung, but I've heard it so much that I was immune to it now. "What about it do you enjoy?”

“For one, I like testing products before they get released to the market. I also like being involved in the process of communicating with the developers, the other test teams, and the customers. I feel like I’m the glue between all those people. But more importantly,” and herein comes a huge grin from me. “I love breaking things.”

To be fair, one of the principles I strive to achieve when testing is to “test to break”. Believe it or not, I’ve always been clumsy even after growing up as a kid who tries to look twice--sometimes thrice--before she leaps. How that turned into me accidentally “breaking” applications and knowing how to work around them was, in a sense, serendipitous. Discovering that I had a knack for finding errors and being able to document them well enough to create detailed bug reports then, in a sense, almost felt like I was meant to be working for the QA field.

I’ve worked for around 2 years as a software developer (plus the four years I spent as an undergraduate in Computer Science trying to learn all the concepts in IT and cramming them in my head), and more than 3 years as a Quality Assurance Engineer (well, “Component Owner” is the more accurate terminology, but it’s essentially a combination of working as a QA Engineer and a Bridge Engineer rolled into one).

And while working on projects that required me to work overtime fixing bugs, only to be the bearer of bad news for schedule delays had traumatized me into not touching code for a very long time, working in the QA field has allowed me to rebrand myself.

It’s the same type of story as those monkeys comparing themselves to birds and being sad about their inability to fly or whatever analogy inspiration posts could come up with, but as time went on, even though I did miss coding from time to time, I did end up taking a liking to work as a QA Engineer.

Quality Assurance work is probably one of the most underrated (and overlooked) fields of work in the IT industry. I’ve talked to several development team members who have thought that the role was unessential to the team, or worse, have thought that running tests on their own was equivalent to having someone else who’s specialized to do testing was just about the same.

To be honest, I’ve been in the shoes of those who misconstrued the importance of quality assurance. In a time where businesses that don’t use automation are seen as lagging behind their peers and AI usage is on the rise, doing things manually and repeatedly has just become too tedious; too monotonous; too boring. But then again, what job isn’t?

There are quite a few things I would like to clarify about some misconceptions from the people I’ve encountered. I wouldn’t claim to remember all of those, but here are some that I could remember off the top of my head:

1. Automated Testing and Manual Testing are both done for very different purposes.
   Manual testing is needed to be done to verify if the service or application could be automated in the first place. How would the user interact with the system? How would the user react to certain changes? Remember that it’s people who will be using these services and applications, not machines.
   On the other hand, Automated testing is important to reduce manual effort and errors on tedious tasks, like regression tests, load tests, etc. Automated testing isn’t supposed to remove the job of the manual tester, but rather, it’s supposed to help make life easier for all parties involved in the development process.
   The bottom line is, both are important and aren’t supposed to take away from one another, Rather, they’re supposed to support each other to make the application better.

2. Becoming a good QA Engineer requires the same time and effort as becoming a Software Developer.
   When I asked someone what they thought QA Engineers did, they painted me a picture of someone repeatedly pushing buttons while drooling. So then I thought, I guess you can get hired as a QA Engineer even if you’re—apologies for the choice of words herein—dumb as fuck. Becoming a QA Engineer myself proved me wrong. I had to think of ways to fix environment setup issues, overcome deadlines, increase work productivity, and additional tests to run to ensure that the application is working as expected. Becoming a QA Engineer made me think outside of the box and look at so much more documentation than I expected.

3. Both Testing and Development require critical thinking, but for different reasons
   Kind of a similar idea as the previous point, but to expand on this, development requires critical thinking to solve a problem; testing requires critical thinking to verify if the features of the current application meet the requirements, and of other ways to break the application.

4. Software Developers have a lot to say in their code. QA Engineers have a lot to say in their bug reports.
   One finds joy in finding bugs. Another, bearing the brunt of that suffering
   One finds joy in fixing things. Another, meticulously looking at it again and again before finally saying “okay” and closing the bug ticket.

5. QA Engineers are not "villains". We're just here to help.
   There's a remark that I heard from someone when I introduced myself as a QA Engineer. I can't quite capture the complete essence of the exchange in writing, but it went something along the lines of how the people doing the testing always end up fighting with the developers over which items are bugs and which ones are features.
   There's an acceptable range between "working as designed" and "limitation" before they overflow and reach the extent of becoming a bug, but it's always up to the teams to discuss the boundaries of each one. Communication is always an essential part of becoming an effective QA Engineer, and it's pretty hard to communicate with devs who think that every bug report is a nail in the coffin.
   After all, at the end of the day, the entire team just wants to make an application that works for everyone, right?

No matter what your motivation is to work in either field, all that matters is that you like doing your work and that you’re in a healthy and safe workspace.