Use test automation as the bridge. Write more and better code in your QA role, pick one development stack that matches your product, take small development tasks inside your current team, and ask for an internal move before you apply outside. Your testing mindset is an advantage, not something to hide.
What people tell me
I have worked in QA for a few years, mostly manual testing with some automation. I enjoy the technical side and I want to become a developer, but I feel stuck with a QA label. When I apply for developer roles, I either get no reply or get offered QA roles again. I am not sure whether to start from scratch, learn a new stack, or try to move inside my current company.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Automation code is real code; grow it until your daily work is mostly programming.
- Pick the stack your product already uses, so your learning connects to work you can show.
- An internal move is usually the fastest path because your team already trusts you.
- Show developer-style evidence: pull requests, a deployed project, clean code with tests.
- Present QA experience as a strength: you know how software breaks.
Your QA years are not wasted
QA engineers often talk about their experience as if it is something to apologise for. It is not. You already understand requirements, edge cases, release cycles, bug reports and how real users break software. Many developers learn those things slowly and painfully. What you need to add is the ability to design and build features, and proof that you can do it.
Why applications keep sending you back to QA
Recruiters match titles. If your last three titles say QA, your CV lands in the QA pile, no matter what you write in the summary. That is why the most reliable routes are ones where your title changes before you apply outside, or where you can show developer evidence that is too strong to ignore.
The bridge: automation
Test automation is the easiest bridge because it is already part of your job.
| Stage | What you do | Signal it creates |
|---|---|---|
| Manual tester | Learn a language properly, not just a test framework | Basic coding ability |
| Automation engineer | Write maintainable test code, page objects, fixtures, CI jobs | Real code in the repository |
| Tooling contributor | Build internal tools, test data generators, mock services | Design decisions, not just scripts |
| Developer on the team | Fix small bugs, then small features | Developer pull requests in production |
If you are mostly manual today, start with Playwright or Selenium in the language your product uses. Test Automation University is free and structured.
Pick the stack your product uses
Do not learn a random popular framework. If your company's backend is Java, learn Java and Spring. If it is a JavaScript web app, learn JavaScript, TypeScript and the front end framework they use. That way every hour you study connects to code you can read at work, bugs you can fix and people who can review you.
Use the backend, frontend or full stack roadmap for that stack, and the programming foundations roadmap if your fundamentals are thin.
Ask for an internal move
This is the step people skip, and it is usually the fastest one.
- Tell your manager your goal. Be direct: "I want to move into development within a year. What would I need to show?"
- Ask for small development tasks. Fixing a bug you found yourself is a natural start. Developers are often happy to hand over small fixes.
- Pair with a developer. Ask to shadow code reviews or pair on a feature once a week.
- Keep a record. Link every pull request you author. After six months you want a list of merged developer work.
- Ask for the title change once the work has clearly changed. An internal title change is much easier than convincing an outside recruiter.
If you have to move outside
Sometimes the company has no path. Then build external proof:
- One deployed project in your chosen stack, with tests, a README and a clear problem it solves. Your testing background should show: good test coverage is a differentiator.
- A GitHub profile with regular commits and readable code.
- A CV that leads with engineering work. Put automation frameworks you built, tools you wrote and bugs you fixed in code at the top, and describe manual testing briefly.
- Target roles where QA experience is valued: SDET roles that are mostly development, platform and tooling teams, or companies that ask developers to own quality.
A realistic timeline
With steady effort of eight to ten hours a week, most people I talk to need somewhere between six months and a year to make the move, faster if their company supports it. The first three months feel slow. That is normal.
If you are still stuck
Read How do I get a developer job with no experience? for how to present yourself when your titles do not match yet. If you want a plan built around your current team and stack, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- Five Kinds of API Test and When Each One Earns Its PlaceThe five types of API testing that do most of the work: functional, integration, regression, load and security. What each catches, what each misses, how to spread your effort, and the one-minute check OWASP ranks as the top API risk.
- Why Your Resume Is Not Getting Shortlisted, and How to Fix ItResume not getting shortlisted? How screening really works in 2026, what applicant tracking systems do and do not do, how to rewrite bullets around evidence, and a four week fix plan with referral templates and a checklist.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.