Hi All, Hope you are all doing well,
I am a Test engineer with 4 yr of exp , for a week I am feeling like I have wasted my years for the job I dont love to do, I am thinking to move to dev path, is it correct choice or I am going to step on a new Landmine
I say to the dev path if you genuinely want to do it. It is your choice!
You should read it first before getting into Developer path, it a blunt reply to those who wants to pursue this path. No sweet corner, just pure harsh truth.
Any career move carries risk. But staying in something you don’t love for another 10 years carries a bigger one — burnout, resentment, and wondering “what if.”
Testing is a perfectly good career. But if your gut is telling you it’s not your career, listen to it. Just make sure you’re moving toward something, not just away from discomfort.
You haven’t wasted anything. You’ve been building skills — just not the ones you want to use forever. That’s not waste. That’s groundwork.
Switching paths after four years in testing is a big decision, but I’d gently push back on the frame of “wasted years.” Testing teaches you how software actually breaks — coverage, edge cases, reproducing flaky behavior, reading specs critically. That’s a real engineering muscle, and many of the best developers I’ve worked with started in QA. Don’t throw that context away when you talk about yourself — reframe it as part of your story, not a detour.
Before you decide “dev vs. stay,” try to separate two questions:
1. *Do I actually enjoy writing code, or do I just dislike my current job?* Those are not the same thing. Give yourself a concrete trial: pick one small thing you’d want to automate in your testing work — a flaky-test dashboard, a script that diffs two API responses, a tiny tool that generates test data — and build it end-to-end on evenings over a couple of weeks. If you finish it and feel energized, that’s a real signal. If you feel relieved to stop, that’s also a real signal. Don’t decide based on a week of feelings; decide based on what building actually feels like.
2. *What “dev path” are we talking about?* “Developer” is not one job. SDET / test automation engineer is a natural bridge from where you are and is often a faster transition — you keep your domain value and grow into writing production-style code. Backend or platform work is a bigger jump but doable. Frontend is the most crowded lane for career switchers right now. Pick a specific role, look at ten real job descriptions for it, and work backward into a skills plan. That’s much more useful than “become a developer.”
A few practical notes. Don’t quit your job before you’ve shipped at least one non-trivial project you’d be willing to walk an interviewer through. When you do start applying, lead your resume with “QA engineer transitioning into X” rather than hiding the testing background — recruiters read “4 years of test engineering” as dependability, and hiring managers read it as “understands production.” Expect the first 20–30 applications to feel brutal; that’s the tax everyone pays, not a sign you made the wrong call.
Four years in is early, not late. You have plenty of runway — just be deliberate about the next six months.
Four years in test engineering isn’t wasted. You’ve built system-level thinking, edge case intuition, and debugging skills that most junior devs don’t have, and those translate directly into being a better developer than someone who only ever wrote happy-path code. The pivot is completely doable, but start building projects and shipping code now while you’re still employed rather than quitting first, because “test engineer who already codes on the side” is a way easier sell in interviews than “unemployed career switcher.” Before you make any move though, write down the best work you’ve done in your current role — complex test frameworks you built, bugs you caught that saved production, automation you designed - because that’s career capital you’ll draw on in dev interviews and it’s the kind of detail that disappears from memory fast once you leave.
I like using ImpactLogr
Just keep it in your own words and experience, not copies of internal test plans or proprietary tooling docs.