Making a switch from QA to Dev

9 min readJun 13, 2021

Career transitions are tough and when you are starting out, you most certainly scrabble around different roles before you encounter the one which makes you go Woah!!! “Now this is something which I would love to do”.

I started my career as a QA before finding my true love with Experience Technology aka Frontend development. The switch from QA to Software development is one of the most common domain changes in the Industry and this story delves into my ordeal of how I managed to make the transition and what were the lessons that I learned along the way.

Kick-Off!!

When I initially got into IT it was unchartered territory for me as I was the first person in the family who had anything remotely to do in corporate, and there were no footfalls for me to follow. However, I knew my profile was of a QA(Quality Assurance) Engineer to be precise and that’s all I knew about my role. I literally had no idea what it meant when it came to actual work and I was too sheepish to ask anyone for an explanation for the role. What I knew though was that I had cracked a couple of hour-long technical Interviews in Java and C, so this role certainly had something to do with tech.

It didn’t take long for the training to get up and running and I was introduced to a whole bulk of technological training in Java, Web technologies, Automation using selenium, and a host of other testing tools. It was exciting no doubt, but I was peculiar about the training durations assigned for the same. For eg:- JAVA training was allotted a total of 5 days and the naive me wondered as to how we were supposed to work as professionals in a technology which we were allotted 5 days to learn. Slow claps!!!!

Lesson 1: The first step to receiving an answer is being brave enough to ask a question — Kaitlyn Bouchillon

It all went in a blur and soon our group was assigned an internal project along with another batch of Devs. We had to work in unison and play out our roles to the tee and get the project delivered. It is here where I first understood what the role meant and what were the tasks I had to carry out. Soon we were assigned shadow projects and off we went on our separate voyages.

The Burnout Phase !!

I always believed in delivering a task to perfection and that’s what I did when I got my chance to work as a QA. It was really exciting figuring out the edge cases and I felt a sense of ingenuity when I succeeded in breaking the code. With time, this initial excitement slowly started to mutate into a state of desolation. Sometimes I felt it was all due to being overwhelmed with tasks and things would settle down once I got a breather. Earning a few accolades and being genuinely appreciated in the team seemed to tranquilize the negative emotions, but the sense of fulfillment was never there.

Photo by Nataliya Vaitkevich from Pexels

Other batchmates of mine found the work fulfilling so I felt I was just being snobbish with my assignment and things would turn themselves around in the coming months. As time passed I gained a few accolades and was duly appreciated for my contributions, but I never got a sense of fulfillment. It was not that I knew I was not enjoying the role and had to do something about it, the core problem was that I never knew what the problem was. I had to act and act soon.

Getting the formation right

So I decided to act….

I took a pen and a paper and started to list out the pros and cons that I seemed to associate with my work. I was really surprised when I found that the list of pros seemed to outgrow the list of cons by a lot. The only thing I seemed to dislike about my role was its detachment from coding and the manual tasks that were part of the regimen.

Lesson 2: Try and understand what genuinely excites you

When I deep dived into my conscious, I realized that it is exactly what it was, the most fun part I felt being a QA was breaking the code, which involved understanding the problem and then formulating a solution in my head and then devising the cases which I might have skipped as part of my solution, fool-proofing it and again breaking it with some other scenario. Voila!!!! It was right before me — I actually liked to solve problems and here I was pretending to like to find them.

I actually liked to solve problems and here I was pretending to like to find them.

Formulating the strategy

I now knew I had to make a transition to Development but I didn’t have any directions or inputs on how to bring that into effect. The best thing about my workplace was that everyone was open to share their knowledge, experience, and suggestions and so I started connecting with people in development to understand the role better. By now I had enough idea about the development roles that existed, but I had no idea about what sub-domain of development interested me. Through my interactions with devs though I slowly began to gravitate towards frontend development and then someone introduced me to Codepen. On Codepen I saw people develop insanely cool animations and trust me when I say this it was surprisingly the stuff that got me interested in frontend. Frontend devs please don’t hate me for the statement I am about to make next.

I fell in love with Frontend development because of how cool CSS was.

It was sorted then, I was going to be a frontend developer and I was going to learn everything about it before I made my move or so I thought.

Lesson 3: Always have a definite goal in mind before making a move

Making a blind run

I quickly started ramping myself up and learned some basic HTML and CSS. I then moved towards JS and then moved back and forth across topics. Now, this is in reality, the most confusing part in your transition journey, when you are confused about making a move. I know you feel like you should make a move when you are perfectly ready but that’s the catch, you never really are. This is a mistake that I feel I made, I waited far too long.

Lesson 4: Always have some preset parameters to measure your progress

So my suggestion would be to let your coworkers know your aspirations, demonstrate your skills to them and get frequent feedback. Also, try and help them with some preliminary bug fixing. It helps you in a couple of ways:-

You get to know if you are at a transition level or not, rather than wait infinitely for the perfect moment.
It helps you break out of the shell of your previous role and internal referrals do work.

Also, try and connect with people who have only just started on a similar role as they might give you a better insight into the possible challenges you may face.

Lesson 5: Try and seek any possible help that benefits your cause

I would then advise you to connect to your manager regarding any internal opportunity and if that works out the transition would be smoother, plus you will have de facto approval of the development team you have already interacted with. One of my close friends made his transition similarly. Nevertheless, this didn’t work out for me as my project didn’t have an outstanding requirement for a frontend dev, so I reached out to the leadership. I demonstrated to them whatever exemplary work I could muster, and I feel rather than my skill they were moved by my enthusiasm.

I made a blind run, and I was very fortunate that I was rewarded for it. I was placed into formal training and thus began my transition into a development professional.

Lesson 6: If you feel you have prepared enough, If you feel you have been stuck for a while and If you feel you have what it takes to move ahead but still are unsure to take the next step, trust your guts and take a leap of faith

Locking in on the goal

As soon as I was assigned to the formal training I got to work, my motivating factor was that I had to make up for time lost in months, and the best possible way for me to do that was not to solely rely on the technical training. I began to search for resources on youtube and other educational sites, started contributing on Github, connected with more people working on live projects and understood different project architectures from them. It was at this point I found some of the greatest sources, that I still refer to this day. Sharing some of them here as well.

If there is one channel on youtube that has an organized playlist for any possible Frontend topic it is “The net ninja”
If you are in search of a CSS guru then there is none better than “Kevin Powell”
Some of the most premium content on frontend topics can be found at “JSConf”
Some other websites I frequently referred to for practice or learning stuff were w3Schools, MDN, freeCodeCamp, JSFiddle, Codepen.

Also would like to suggest that read as much code as you can, it is a very grossly underrated factor when it comes to learning how to code. Reading other people’s code opens up a ton of different perspectives to your natural way of thinking.

Everything went in parallel for a few months and it was time for me to formally take up a project. I had tried so hard for this moment to arrive and it was finally here.

Lesson 7: Do or do not. There is no try. — Yoda

The Final step

I was tensed before the internal interview as this was the culmination point for all the hard work that I had done in the past few months. I was pleasantly surprised how the interview went and I realized I had finally done it, I had made the transition and it was all thanks to all the positive people who helped me along the way. After making my transition I never looked back, I kept all my focus on my learning and realized it was easier to close the gap on people, because it is very rare for working individuals to keep ramping themselves up voluntarily, and it is one quality I feel which has helped me stand out since then.

The most valuable lesson I gained from my journey was that roles were nothing but an accumulation of skills and it was always possible for an individual to take up a new role provided he was determined enough to gain the skill set required for the same. Always plan ahead and execute it to perfection.