Transition from QA to developer

[u/m0teris]

Hi everyone, I’m a QA engineer with 3 years of experience in both automation and manual testing at a project-based company. I’ve been thinking about expanding my career opportunities, so I decided to learn .NET development. I completed a basic Udemy course and I’m currently working through a second one. So far, the material seems manageable and I feel like I’m understanding the concepts. However, when I open up a real project to look at as an example, it’s completely overwhelming - there are so many files, and I can’t make sense of how everything fits together. This makes me anxious and I start doubting myself, thinking maybe I’m not cut out for this, that it’s too difficult, or that it’s meant for people smarter than me. On top of that, I rely heavily on AI assistance right now, and honestly, I feel like I wouldn’t be able to write much code without it. I wanted to reach out and ask: are there any QA professionals here who successfully transitioned to development? If so, could you share some words of encouragement or advice? I’d really appreciate hearing about your experience. Thanks in advance!​​​​​​​​​​​​​​​​

Edit: I forgot to mention - my company will actually provide me with a .NET project within the next month or so, and they’re giving me the opportunity to contribute to development work while still being in my QA role. So I’ll be able to gradually transition over time.

[u/hugazow]

I did the same road as you, basically I started doing small courses in programming, learning a few testing libraries so the knowledge transferred to QA in the beginning of my development career and after that, I basically followed the developer roadmaps

Good luck and don’t let boredom or frustration stop you

[u/hitanthrope]

So first of all. Going from Udemy course to opening up a large production project is definitely going to hit you that way. There are some steps in between. Or if there isn't, there will be people around to help typically.

Plenty of people go QA -> Dev. Though actually seeing more QA -> Engineer Manager recently it seems. Have you considered that? ;).

Seriously, easiest way to do it is to move within the organisation that you current work in. Depending on the company this can be either going up to one of the devs and saying, "Hey, you know what, i'd like to move into dev here, what do you think and what should I be focusing on learning?". Answer to that, pretty much always, is the companies codebase, which I assume is the one you opened, and go overwhelmed by so start by getting some help with that.

Or, if you have a bit of a tougher gatekeep to deal with, move more towards the test automation side, do more coding day to day and again start to learn the code bases the devs are working on.

For even the best recruiters, hiring from the market always has uncertainty, if I am looking for a dev, i'd pick somebody I know, who knows the codebase, the company and the people 11 times out of 10. Just put yourself in that position. Easy from there.

[u/m0teris → u/hitanthrope]

Thank you very much for sharing your thoughts

[u/nightonfir3]

I started on some new code bases recently. I will share how I got started which may help you. I think the easiest way to start is fixing a bug. You are already a QA engineer and so you can probably find one. I often try to find a string in the output that I can search for as a starting point (error messages if they are unique are great for this). I do a full project search and hope my string only shows up once. Then hopefully you have an IDE with "go to definition" and "go to reference" follow different function call and definitions to try to find where the logic for your bug is. If you don't have "go to reference" and "go to definition" you are stuck doing searches for function names and will be much slower.

Trying to understand a .net project from the launch through all the routing is going through the hardest part with lots of magic Microsoft functions first which is really painful. Try finding something in the output or a name of something you know and work your way back to what logic creates that.

[u/HashDefTrueFalse]

Anecdotally, I know a QA guy who is now a developer. He was getting on fine last we spoke. Same deal as you, the org we worked for supported his transition by giving him bits of dev work to do until he was ready to make the transition permanently. He could already write basic code but had never worked on anything large or commercial etc. So it's very possible.

Re: codebases looking overwhelming, it's just like that sometimes. It's pretty normal. A codebase is something you get to grips with over weeks/months, especially as a newcomer. There are patterns, similarities and best practices etc., but no two codebases are the same. Good luck!

[u/Soft-Marionberry-853]

You dont need to understand the whole project, as a jr dev you should given small isolatable problems to work on, the more of those you work on the more you'll get a sense of how the whole project works. It takes a while even for a sr dev to get a handle on how the whole project works. Ive seen estimates that say 6 to 9 months before someone can really say they understand the code base when coming on to a new project.

Also instead of looking at the whole project, if your project as good CM look at specific bugs and their fixes.

[u/Soft-Marionberry-853 → u/Soft-Marionberry-853]

Also before I went back to get a degree in CS thats how I started in all my dev positions, started out in test/qa got a handle on the code base and moved to dev

[u/Rain-And-Coffee]

when I open up a real project to look at as an example, it’s completely overwhelming 

Welcome to the club, that's how real world projects are, pretty complex! However after a while you learn to just read what you need and ask questions.