14 min read
Most Testers Make a Career Change from QA to Developer in Stages
Most people who make this switch do not leap from manual testing to a developer title in one move. They walk it in stages. A manual tester learns to script, becomes an automation engineer, sometimes takes a software development engineer in test (SDET) role, and then moves onto a product team. Each stage adds more code to the week and more ownership of what that code does.
Testers make this move often for a simple reason. You already know the product, the release process, the people who write the code, and where it tends to break. Someone coming from teaching or sales has to learn all of that on top of programming. You only have to learn the programming, and you get to practice it on a codebase you already understand.
Still, one popular idea needs correcting up front: that QA is a lighter version of development and the switch is just a promotion. The two jobs want different things from you. The federal O*NET entry for QA analysts and testers lists their top tasks as finding problems, documenting defects, reporting them to developers, and designing test plans. Every one of those starts from software someone else made. Testing asks whether the software works; development asks you to make it work and to own it when it breaks.
Career Design System
Which career would actually suit you?
Find out what work suits you and what drains you, so you can stop guessing.
See what fits you →That second part, the owning, takes the most getting used to. A tester who finds a bug at 4 p.m. writes it up and moves on. A developer who caused it is the one still at the keyboard at 7 p.m.
Who Settles In Fastest
Plenty of testers become good developers. The ones who settle in fastest tend to share a few habits before they ever ask for the title. They already write scripts to save themselves time. They read stack traces instead of pasting them into a ticket. They build small tools nobody asked for, like a script that resets the test database or a dashboard that shows flaky tests.
The ones who struggle are often excellent testers. They love finding the problem more than solving it. They enjoy the hunt for the edge case that breaks the checkout page, and they find a blank file with no spec a little dreadful. They suit different work, and it pays to know which one you are before you spend a year of evenings finding out.
Should You Switch from QA to Developer? A One-Month Test
Wanting it badly is not what decides this. What stops most people is finding out, six months in, that they do not like the daily work of building. The question that decides this switch is whether you like the work of building from a blank page.
For the right person, few starting points beat QA, and a career change from QA to developer is one of the shorter routes into building software. For someone who mostly wants the higher pay or the status of the title, it can turn into a long, expensive detour that ends in a job they do not enjoy.
You can check this before you commit, using your current job. Try three things over the next month:
- Fix one bug yourself. Instead of filing it, find the cause in the code, write the change, and ask a developer to review it. Notice whether the hour you spent hunting felt like a puzzle or a chore.
- Build one thing nobody asked for. A test data generator, a small internal tool, a script that saves your team ten minutes a day. Start from an empty file.
- Watch where the time goes. Each Friday, note which task made you lose track of the clock. If it was writing code, that tells you something. If it was an exploratory testing session, that tells you something else.
Still torn after a month? Our guide on whether to change careers at all walks through the bigger question.
The Build Skills to Check Before You Commit
Beyond enjoying it, a few build skills predict how hard the switch will feel. These are habits of mind:
- Breaking a fuzzy problem into pieces. A ticket says “let users export their data.” Can you turn that into ten small steps without being told how?
- Sitting with not knowing. Developers spend long stretches stuck. Testers usually have a clear pass or fail. Some people find the open-ended stuck feeling fine; others find it miserable.
- Making trade-offs. Fast or clean? Simple now or flexible later? Developers make these calls daily, with no test case to tell them they chose right.
- Owning the result. When your code breaks in production, it is yours to fix, often under pressure.
A caution on the money motive: wanting a higher salary is a perfectly good reason to switch. It just does not carry you through a year of evenings on its own. People who finish usually have a second reason too, like enjoying the act of making something.
Step-by-Step Plan: QA Engineer to Software Developer
The fastest route from QA engineer to software developer uses your current job as the training ground. Every step below builds on the one before it, so do them in order rather than all at once.
- Pick one language and go deep. Choose the language your company's product is written in. If your team ships Java, learn Java. If you already automate tests in Python or JavaScript, stay there. Depth in one language beats a little of four.
- Automate your own work. Turn your manual test cases into automated ones. Build or extend the test framework. This is code in your company's repository, reviewed by developers, and it shows up in your work history.
- Build two small projects from start to finish. Two working apps you designed yourself, each with a database, a few screens or endpoints, and your own tests. These are your proof that you can build, not only check.
- Take developer tickets at work. Ask your lead for small bug fixes or low-risk features. Pair with a developer. Get your changes through code review. This is the step most people skip, and it is the one hiring managers trust most.
- Choose your route out. Decide whether you are aiming for an internal transfer or an outside job hunt (more on this below), then prepare for coding interviews on the route you chose.
Code you shipped at your current job counts for more than any course certificate, because a reviewer already trusted it. For the wider picture of paths into development for people starting with no tech background, our guide to a career change to developer compares self-taught, bootcamp and degree routes. For a tester, most of that is optional: you already have a foot in the door.
A Realistic Timeline for a Career Change from QA to Developer
The time it takes depends mostly on two things: how much code you write today, and whether your company will move you internally. As a rough guide, not a promise:
- Already writing automation, internal move available: often 6 to 12 months of taking developer tickets before a formal transfer.
- Manual tester, internal move available: often 12 to 18 months, since you are learning to code from scratch first.
- Outside job hunt with no internal route: often 12 to 24 months, because you need a portfolio and you face a slower hiring process.
Plan your money around the longer number. Keep your QA salary while you learn. Quitting to study full time is the riskiest version of this switch, and for a tester it is rarely needed.
| Route | Typical time | Effect on pay | What you need |
|---|---|---|---|
| Internal transfer | 6 to 18 months | Usually keeps your current salary, with a raise at a later review | Developer tickets shipped at work and a manager who backs you |
| SDET role first | 6 to 12 months to get the SDET job, then 1 to 2 years | Often a raise at the SDET step | Strong automation work and a test framework you built or improved |
| Outside job hunt | 12 to 24 months | Can dip if you take a junior title | Two solid projects, coding interview practice and a rewritten resume |
The internal route is usually the better deal. Your company already knows you are reliable. It saves on hiring. And you skip the stage where a stranger reads “QA” on your resume and moves on. Ask your manager directly whether QA staff have moved to developer roles before, and what it took.
Developer Interviews from a QA Background
Interviews for developer roles test different things than QA interviews did. Expect three kinds of rounds, and prepare for each on purpose.
- The algorithm round. A timed problem on lists, maps, strings or trees. Practice two or three problems a week for two months in the language you chose, and say your thinking out loud as you go. Testers have an edge here: talk through the edge cases before the interviewer asks.
- The take-home task. A small app or feature to build in a few days. Treat it like real work: a clear README, small commits, and your own tests. This is where your QA years show best, so make the tests good.
- System-design basics. Junior roles rarely go deep, but you may be asked how you would build something simple, like a URL shortener. Know how a web request travels, what a database and a cache are for, and when a slow query becomes a problem.
When they ask why you are moving, tell the story of your career change from QA to developer in three lines:
- “I spent X years in QA, and I kept writing code to make the testing faster.”
- “Over the last year I shipped developer tickets at work and built two apps of my own.”
- “I want to own what I build now, and my testing years mean I build it to hold up.”
Skills Needed to Go from QA to Developer, in Order
The order you learn things in matters more than the list of things, because each layer rests on the one below. Here is the order that tends to work for someone coming from testing.
1. One language, properly. Enough to write a whole program: functions, classes, error handling, reading other people's code. JavaScript is the most widely used language in the 2024 Stack Overflow Developer Survey, with 62.3% of respondents using it in the past year, and it pairs well with test tools you may already know, like Playwright or Cypress. Python and Java are sound picks too, especially if your company uses them. The same survey found online resources were the top way developers learned to code, at 82% of responses, so you do not need a classroom. Mozilla's free web development lessons are a solid start for JavaScript.
2. Git and code review. You likely use Git a little. Developers live in it: branches, pull requests, resolving conflicts, and taking review comments without flinching.
3. Data and the basics of how computers handle it. SQL, a few core data structures (lists, maps, sets), and a feel for why one approach is slow and another is fast. You do not need to master algorithm puzzles to work, but many interviews still ask them.
4. One framework your company uses. Spring if you are in a Java shop, Django or FastAPI for Python, React and Node for JavaScript. Pick the one you can practice at work, not the one trending online.
5. Design, last. How to split code into parts, how services talk to each other through APIs (the agreed ways one program asks another for data), and later, how larger systems are put together. This is the layer QA rarely touches, and it is what separates a junior developer from a mid-level one.
For a tester, the gap is rarely the language; it is design, the part of the job testing never asked you to do.
The SDET Bridge
The SDET role is the usual bridge from testing to product work, with no big jump in the middle. An SDET writes production-quality code whose job is testing: frameworks, test tooling, pipelines that run checks on every change. It is a development job with a testing focus.
That makes it a useful middle step. You get a title with “engineer” and “development” in it, your code gets reviewed like any developer's, and your next move to a product team is a sideways step rather than a leap. Some people stop here, because they find the SDET work suits them better than feature work. That is a good outcome too.
What Your Testing Years Give You and What They Don't
Your testing background helps in specific ways. It also leaves specific gaps. The switch goes best when you know both sides.
What carries over
- You think in edge cases, so your code breaks less often.
- You know the whole system, not just one corner of it.
- You read logs and reproduce bugs fast.
- You write clear tickets, which makes you easy to work with.
- You see the product the way users do.
What does not
- You are used to checking work, not designing it.
- You have had little say over architecture.
- Speed and memory use were someone else's concern.
- You may wait for a spec instead of writing one.
- Your title says tester, and some screeners stop there.
Your QA years make you a careful developer, but they do not teach you to design, and interviews test for design. Keep the testing background, add the missing half on top of it, and show both.
How a Hiring Manager Reads a QA Resume
Some recruiters filter out QA resumes for developer roles by title alone. That is not fair, but it is common, and it is why an outside job hunt is slower for testers. You can get around most of it.
Lead every role with code you wrote, not bugs you found. “Built a Playwright test framework in TypeScript now used by four teams” reads as a developer. “Executed 400 test cases per release” reads as a tester. Put your two projects near the top with links. List the developer tickets you shipped. Our guide to writing a career change resume covers how to order sections when your past titles point one way and your goal points another.
In interviews, use the three-line switch story from the plan above: what you built, why you moved toward building, and what your testing years taught you about writing code that holds up.
QA to Developer Salary: What Happens to Your Pay
Here are the real pay numbers. In the federal Occupational Outlook Handbook from the BLS, the median annual wage in May 2025 was $104,300 for QA analysts and testers and $135,980 for software developers. The middle tester earns $31,680 less than the middle developer.
But a median compares a typical tester with a typical developer. It does not tell you what a career change from QA to developer does to your own pay in year one. That depends on which route you take.
What Your Pay Does in the First Year After the Switch
If you move internally, your salary usually stays where it is on the day you change teams. Companies rarely cut pay for an internal move, and your raise tends to come at the next review cycle, once you are performing as a developer.
If you job hunt outside as a senior tester, it can go the other way. A senior QA engineer who takes a junior developer job can land below their current pay for a year or two, then pass it as they reach mid-level. A manual tester earning less than the QA median may see a raise straight away. The pay cut is a feature of the outside route and the junior title, not of the switch itself.
On timing, build in a cushion. If your plan assumes 12 months, save as if it will take 18. Keep your QA job until you have an offer. The emotional cost matters too: expect a stretch of feeling like a beginner again after years of being the expert. That feeling is normal, and it fades once you ship a few things.
Mistakes When Switching from QA to Developer
The switch usually fails in a handful of predictable ways. None of them is about talent.
- Quitting before you have proof. Leaving QA to study full time throws away your best asset: a paid seat next to the code.
- Getting stuck in tutorials. Finishing course after course feels like progress. Building something without a guide is what moves you.
- Leaving the company that would have moved you. Many testers job hunt outside without ever asking about an internal transfer.
- A resume that says tester all the way down. If the first line of every role is about testing, screeners will read you as a tester.
- Interviewing as a tester. Talking about bugs you caught instead of things you built and decisions you made.
- Taking rejection as a verdict. Outside job hunts involve many rejections for everyone. Track what each interview asked, fix the gap, and keep going.
- Skipping the self-check. Spending a year learning to build before testing whether you enjoy building.
The last one is the most expensive, because it costs the most time. The costliest mistake is spending a year learning to build before checking whether you like building. The one-month trial earlier in this guide helps. So does a structured outside view of how you work.
Pigment's career test is one such view, a science-backed assessment of how you work. It looks at whether you get more from making new things or from making existing things better, how you handle open-ended problems, and how you like to make decisions. For a tester weighing a career change from QA to developer, that speaks to the question under all the others: do you like making things enough to do it every day? It points to roles that line up with how you work, whether that is product development, SDET work, or staying in quality with more seniority. It costs $79.
If you are making this move later in your working life, our piece on an IT career change at 40 covers what changes with age, and what does not.
FAQ
Is it possible to climb up from QA test engineer to SWE?
Yes. Many engineers started in QA. The common path runs through automation and often an SDET role, then onto a product team. Shipping developer tickets at your current job speeds it up the most.
How long does it take to switch from QA to developer?
Roughly 6 to 12 months if you already write automation and your company moves people internally. Plan on 12 to 24 months if you are starting from manual testing or job hunting outside.
Will I take a pay cut switching from QA to developer?
On an internal move, usually not. You might on an outside move into a junior title, especially from a senior QA salary. Over time developers earn more: the BLS median was $135,980 against $104,300 for testers in May 2025.
Can QA engineers become good developers?
Yes. Testers bring edge-case thinking and system knowledge that many developers lack. The ones who do best also enjoy building from scratch and learn design, the part testing never covered.
Is QA experience a disadvantage when applying for developer jobs?
Only if your resume hides the code. Some screeners filter by title, so lead with what you built, link your projects, and list developer tickets you shipped. In the interview, your testing years become a strength.
What skills do I need to transition from QA to developer?
Learn in this order: one language properly, then Git and code review, then SQL and basic data structures, then one framework your company uses, and design last. For most testers the gap is design, not the language.
