From QA to Back-end: Moving to Another Planet
It will soon be 2 years since I have moved from QA Automation to Back-end engineering. I can’t say this was my initial goal when learning to program. I was just interested and decided to give it a shot.
But some time later, when I reached some level of expertise in QA automation, I started feeling that there is some lack of fundamental knowledge that I thought I should have as a software engineer (surprise, a QA is also considered an engineer).
The main paradox of the situation is that even being a Senior QA engineer in a solid development company, you may not need any deep knowledge in Computer Science.
Of course, tech companies are to be blamed for this.
In my local tech domain, companies usually set a significantly lower threshold of CS knowledge when interviewing QA candidates. There are very few companies or startups that will interview Senior Automation QA candidates as they do that for a Senior Developer (I mean the technical part of the interview).
I understand that the roles of a QA and a developer are different. But the two require at least some engineering knowledge (if you know what I mean).
So, here is me, mid or maybe even senior QA Engineer who constantly reads about data structures, language-specific features, databases but can’t see where to use all the consumed knowledge to transform it into a solid experience.
The decision I made? I moved to development, to the back-end.
So you guys might be reading this and waiting when I am going to list the 100% working tips on how to move from the QA to the development team. Nope, there are no 100% working tips there.
I will just tell you how my transfer was. If you think you can take something useful from here that will help you become a developer or create your personal Galactic Empire, please don’t be shy, take it.
Before I start, just keep in mind that I was really lucky, because of some circumstances and factors.
So all XP points I am going to list will be multiplied by two if you are lucky than average.
A prudent employer
Say, you approach your employer who pays you a competitive salary for you working as a competitive QA engineer and tell them you want to become a back-end developer.
In my case, I was really lucky to be given the chance, even more, keeping the same salary rate while my real knowledge was barely hitting the requirements the company set for junior developers.
That means your employer is on the same wave and understands that either they give you a chance to become what you want, stay and make cool stuff for their business, or they say “no” and you leave, cause you have already decided to make “Changes” (kudos 2PAC) and you have no enthusiasm working as a QA Engineer anymore.
Decide which type of learner you are
Yes, it sounds like a pathetic text from a regular article about self-development. But the sentence exactly describes my thoughts.
I have met two types of people in tech. The first type is the Academic guy and the second one is the Practical guy. The list is not full. You may find out there are many more types. I have just determined those two.
The Academic guy is a kind of person or in our case, an engineer who takes the documentation of the language reads it from the beginning to the end and shortly after that, he is ready to write production code. Really guys, can someone explain this mystery to me?
Yes, you guessed it right. I am the second type. But it took me some time to find this out. Usually, you find yourself among the Academic guys who read the whole documentation and you try to do the same. Usually in vain. Then lightning strikes your head and you simply understand that there are some very specific information digesting tips that are only applicable to you.
Summary of this point. Accept that you might consume and materialize information in a different way and that’s ok.
Read a lot and write code based on what you have just read
Already chilling because I said that you don’t need to read the documentation?
Maybe, in the beginning, you will dodge documentation readings (like Neo was dodging agents’ bullets).
It’s a double-edged sword (cliche). Yes, at first I was writing code and going to documentation (or to my mentors, no difference for me :D) only when I needed to look something up. But when that phase passes you have to go through all or most of it to get the bigger picture. You need to grow, otherwise, you will always be that “toddler” asking seniors to help you.
Going back and reading the code you wrote as a QA
You are a senior QA. You write your code, run automation suites, results are good, you admire your code. Then you become a developer, come back and read your QA code. I bet I am not the only one who said — “Oh my goodness, what a crap.”
Even more, this happens even when you go back to the code you wrote as a developer in the beginning. Advice is to do this “denial-awareness-acceptance” circle regularly, so you never think that your code is outstanding. Dwelling in your comfort zone will crush you into subatomic particles like a black hole.
Summary
You might think from what I wrote that I am saying that being a QA is not as interesting and challenging as being a back-end engineer. No, that’s not true. QA is part of engineering and
there are vast challenges that you will face when doing it.
What I am seeing is that due to some local tech domain requirements, you may find that there is no more place to go and you are stuck. Even if you work on yourself and try to push yourself forward you will come to the same, because there is no demand. And I found two ways to resolve the situation.
Either you change your work, I mean geographically move to another country, region where there is a much stronger demand for a deeper knowledge and you will amaze everyone with your QA technical expertise, or you move to another type of engineering.
I went with the second option because I was not a die-hard, dedicated QA engineer. I just like coding and wanted to do more and I found that possibility in development.
P.S. Yes, at some point the same dead-end will happen to a developer but it will be much later. Then I guess, I will have to write another article.
Check out our open roles at https://sflpro.com/job/.
Read More:
