You have two, five, or eight years of QA experience, and you want to write code for a living, not just find the bugs in someone else's. Every job posting you actually want says "Software Development Engineer," not "QA Engineer." You have read a few forum threads and a community wiki FAQ, and every answer sits at one of two extremes - "it's basically impossible," or "just learn to code" - with nothing in between about what to actually do on Monday morning.
This is the plan for the middle. It treats your QA background as a real asset, not a handicap to apologise for, and it gives you a six-month sequence that ends with either an internal title change or a developer offer you can defend in an interview - built from what has actually worked for testers who made this exact move, not from a bootcamp sales page.
Why the QA to developer switch feels impossible (and why it is not)
Search for this transition and you will mostly find two kinds of pages: raw forum threads with no structure, or course pages that need you to believe the switch is hard enough to justify a fee. Neither is written for someone who already has a job and three years of context on how software actually breaks.
Here is what the forums get right and the course pages leave out: you are not starting from zero. A tester who has spent two years writing test cases already understands requirements, edge cases, and how a feature fails in production - the exact things a fresh computer science graduate has to learn the hard way, on the job, usually by breaking something.
What you are missing is narrower than it looks. It is depth in one programming language, comfort with data structures and algorithms at an interview level, and a portfolio that proves you can build a feature, not just verify one. That is a real gap. It is not a five-year gap.
Internal transfer vs quitting: which path is actually faster
The forums default to one plan: quit, study full time, apply everywhere. It is rarely the fastest path, and it is almost never the lowest-risk one.
Before you resign, check whether your current company allows a lateral move from QA to development. Product companies and larger services firms often do, especially for testers who already work close to the dev team.
| Path | Speed | Salary risk | What it depends on |
|---|---|---|---|
| Internal transfer | Slower to start, no interview loop | Low - usually keeps your pay | Your manager's support and an opening headcount |
| External job-hop | Faster to start | Higher, if your portfolio is thin | A portfolio strong enough to be judged on skill, not title |
An internal transfer usually keeps your salary intact, skips the interview loop entirely, and lets you learn the new tools with existing context on the codebase and the people. The trade-off is patience - it depends on your manager's goodwill and a headcount actually opening up, and it can take a review cycle or two to become official.
An external job-hop is faster to start and does not depend on any one manager saying yes. But you are competing against candidates who already have a developer title on their resume, and recruiters commonly price a first developer role against your last drawn QA salary, not against what a developer at your experience level is worth. Budget for a possible pay reset if you take this path with an unfinished portfolio.
The honest advice: try the internal path first, for one real conversation and one real attempt. If it genuinely is not available - your company has no dev openings, or your manager will not support it - move to the external path with the same six-month plan behind you, so you are applying as a switcher with a portfolio, not a QA engineer hoping to be taken on faith.
What you already know vs what you still need to learn
Your QA background is not nothing. It just is not sold correctly on a resume that still says "QA Engineer" at the top.
What you likely already have: a working sense of how requirements translate into behaviour, comfort reading logs and reproducing bugs, basic SQL from writing test data or validating results, and, if you have done any automation, a first exposure to a real programming language through Selenium or Playwright scripts.
What you still need, in order of priority:
- Depth in one language, not a scattered tour of five. Java, Python, or JavaScript are all reasonable choices - pick the one your target companies actually use, not the one with the most tutorials.
- Data structures and algorithms at the level interviews test for, not the level your automation scripts needed.
- Two small, real projects you built end to end, not a cloned tutorial repo.
- Git, used properly - branches, pull requests, a commit history that reads like real work.
SDET - the stepping stone nobody explains properly
SDET, short for Software Development Engineer in Test, is the role between manual testing and a full development seat, and most guides skip past it straight to "just learn to code." That is a mistake.
An SDET builds automation frameworks, writes code against a real codebase, and works inside the same sprint as the developers - which means the jump from SDET to developer is much shorter than the jump from manual tester to developer.
If your company has an SDET or automation-engineer track, moving there first is often the single fastest way to make the bigger switch stick, because you are already writing production-adjacent code before anyone has to take a chance on you as a developer. If there is no SDET track where you work, you can still build the same profile on your own time - the two projects mentioned above should look like an SDET's work, not a QA engineer's.
The 6-month plan, month by month
Months 1 and 2: pick one language and go deep. Finish a proper course or book, not a playlist of unrelated videos. Start data structures and algorithms in parallel, thirty minutes a day, so it becomes a habit before it becomes a deadline. Have the first conversation with your manager about an internal move - early, not after you already feel ready.
Months 3 and 4: build your first real project - something with a database, an API, and a bit of business logic, not a to-do list app. If an SDET or automation-engineer opening exists internally, apply for it now. Keep testing yourself with easy and medium coding problems, three to four a week.
Months 5 and 6: build the second project, ideally something that touches a domain you actually know from your QA work - a test-case management tool, a bug-tracking dashboard, anything where your prior experience is a visible advantage, not a footnote. Update your resume to lead with the projects and the language, not the QA job title. If the internal path has not moved, start applying externally with this portfolio behind you.
Once you are dev-ready and interviewing, our coding interview preparation guide for India covers what to expect next, including the machine coding rounds that catch switchers off guard.
The money question, honestly
Payscale-reported data for India puts SDET compensation above manual testing and below a mid-level developer, which matches the role's position on the ladder - it is a real step up, not a lateral move with a new title.
A straight external job-hop from QA to a developer role, without the projects or the DSA practice, is where the pay reset risk is highest, because recruiters have nothing but the QA title to price you against. An internal transfer is the version of this switch least likely to touch your salary, because you are moving inside a role your company already knows you can grow into.
Treat the six-month plan as insurance against the reset, not as a guarantee against it. A stronger portfolio narrows the gap. It does not erase it.
Not sure if your company even allows this move?
Twenty minutes with a working developer who made this exact switch beats another week of forum threads. Talk to a Guide who has done it, inside a company like yours.
The mistakes that turn 6 months into 18
- Learning three languages instead of one. Depth in one beats a shallow tour of many, every time an interviewer asks a follow-up question.
- Skipping data structures and algorithms because your test automation background feels close enough to real coding. It is not the same skill, and most developer interviews test it directly.
- Building only tutorial-clone projects. A project that looks identical to five thousand other GitHub repos proves you can follow instructions, not that you can build.
- Quitting before you have had the internal conversation. You cannot know it is closed off until you have actually asked.
- Treating this as a resume edit instead of a skill build. Changing your title without changing your skills gets caught in the first real interview.
How to raise it with your manager
The conversation is simpler than it feels. Ask for fifteen minutes, and say plainly that you would like to grow into a development role and want to know if there is a path to do that on this team.
Come with two small facts already true - a language you are learning and a project you are building - so the ask sounds like a plan already in motion, not a hope you are floating. Ask a specific question: is there an SDET opening, or a chance to pair with the dev team on a small feature, in the next quarter.
A manager who says no outright, with no path and no timeline, has given you a real answer - and a reason to start the external track in parallel, not instead. If you are weighing this as part of a bigger move, not just a title change, our career change at 28 guide and our service to product company switch guide both cover the wider decision.
Key takeaways
- Try the internal path first. One real conversation, one real attempt - it is usually faster and lower-risk than quitting and job-hunting from zero.
- Your QA background already covers requirements, edge cases, and reading logs. What is missing is depth in one language, DSA at interview level, and two real projects.
- SDET is the real stepping stone between QA and developer - use it if your company has the track, or build the equivalent profile yourself.
- A pay reset is a real risk only on the external path with an unfinished portfolio, not on a well-prepared internal move.
- Six months is the realistic budget for either path - two months on language and DSA, two on your first project, two on your second project and applications.
Frequently asked questions
Quick answers about switching from QA to developer in India.
Is it too late to switch from QA to developer after 5+ years?
No. Experienced testers already understand requirements, edge cases and production behaviour - the harder part of software engineering. The gap is technical depth: one language, DSA at interview level, and two real projects. That is a six-month build, not a five-year one, at any experience level.
Will I take a pay cut switching from QA to developer?
A pay reset is a real risk on an external job-hop with an unfinished portfolio, since recruiters price you against your QA salary. An internal transfer, backed by a real project and language depth, is the version of this switch least likely to touch your pay.
Do I need a coding bootcamp to switch from QA to developer?
No. A bootcamp can add structure, but the actual requirements are language depth, DSA practice, and two real projects - all buildable on your own with a course or book and consistent daily practice. A title change without those skills gets caught in the first real interview.
Is SDET a good stepping stone from QA to developer?
Yes. SDET sits between manual testing and development - you write real code against a real codebase inside the same sprint as developers, which makes the next jump to a full developer role much shorter than jumping there directly from manual testing.
Do product companies hire developers with a QA background?
Yes, when the candidate shows real projects and language depth, not just a retitled resume. Product companies filter on demonstrated skill for internal-mobility hires and switchers alike - your QA experience becomes an advantage once you can also show you can build, not just verify.
How do I ask my manager for an internal move from QA to development?
Ask for fifteen minutes and say plainly you want to grow into development and want to know if a path exists on this team. Arrive with a language you are already learning and a project in progress, then ask a specific question: is there an SDET opening or a chance to pair with the dev team this quarter?