Moving from QA into development is one of the most common switches in software, and one of the most natural. You already read requirements looking for holes. You know which parts of the product break and why. You write bug reports that developers can act on. Those are real engineering skills.
What is usually missing is the other half: writing code that other people depend on, owning it after it ships, and the habits around that (branches, reviews, tests that run on every change, deploys). This plan fills that half in 16 weeks at about six hours a week. If you have more time, it gets shorter. If you have less, it stretches, and that is fine.
The idea behind the plan
Three rules shape the order:
- Start from code you already understand. Test automation is real programming, and you know exactly what a good test is for. That makes it the best bridge: the problem is familiar, only the tool is new.
- Skim what you already know. Most QA engineers already use SQL, Git and browser dev tools. Don't sit through beginner lessons out of guilt. Skim them and take the final exam to prove it.
- Build one thing all the way through. A finished, tested, deployed small app beats ten half-done tutorials, in interviews and in your own confidence.
This is the same shape as the QA engineer → developer role switch: test automation as the bridge, three courses to skim, then the Full-Stack Developer path. The planner on that page builds the week plan for the hours you actually have. Below is our version at six hours a week, with the reasoning.
Week by week
The lessons in this plan add up to about 30 hours of reading, listening and quick checks. The other 60 or so hours are practice: the exercises inside each lesson, labs, and your project. If you find yourself only reading, you are behind, however many lessons you have finished.
| Weeks | Focus | Courses | By the end you can |
|---|---|---|---|
| 1–2 | The bridge | Test Automation and Quality Engineering | Turn a manual checkout test into unit, API and end-to-end tests that run in CI |
| 3–5 | The language | JavaScript Deep Dive | Explain closures, the event loop and async/await, and debug them |
| 6 | Skim and prove | How the Web Works, SQL & Data Modeling, Git from the Inside | Pass three final exams without taking every lesson |
| 7–8 | Working in a team | GitHub for Teams | Open a pull request, review one, and run a GitHub Actions pipeline |
| 9–11 | The front end | React for the Web, JavaScript in the Real World | Build a small React page that loads data and handles errors |
| 12–14 | The back end | Building APIs with Node.js | Build an API with a database, auth and background jobs |
| 15–16 | Ship it | Ship a Project End to End | Deploy your project and write its README |
If you have never used a terminal or set up a code editor, add Your Developer Setup in week 1 and push everything back a week.
Weeks 1–2: the bridge
Start with A test strategy, not a pile of scripts. It maps checkout risks to test levels, which is the thinking you already do, written down. Then automate a real flow: the course builds tests for Mangrove Market's checkout at the unit, API and end-to-end level, then runs them in CI.
In parallel, open the Code Lab and do the free JS Basics campaign. It is five short challenges checked by tests, which will feel familiar.
Weeks 3–5: the language
Most people who stall in a switch stall here. JavaScript looks easy until async code runs in an order you didn't expect. Take The event loop and Async JavaScript slowly, and do every exercise. In the Code Lab, the free "Retry a flaky payment call" template is good practice: it is a bug you have probably reported before, now from the other side.
Week 6: skim and prove
You probably know more SQL and Git than you think. Skim How the Web Works, SQL & Data Modeling and Git from the Inside, and go straight to each course's final exam. Exams and certificates are free. Where you fail a section, go back to that lesson only.
Weeks 7–8: working in a team
Developers spend a lot of their week in pull requests. GitHub for Teams covers reviews, branching and Actions. Put your week 1–2 tests into a GitHub Actions pipeline so they run on every push. That is your first piece of portfolio work, and it shows something many junior developers can't: a test suite someone can trust.
Weeks 9–14: front end, then back end
Now build features, not just tests. React for the Web and JavaScript in the Real World give you a page that loads data and copes with slow networks. Building APIs with Node.js gives you the server: a NestJS service on PostgreSQL, sign-in, and background jobs. Keep your testing habit: every feature you build gets a test at the right level.
Weeks 15–16: ship it
Pick one small, real-feeling project and finish it. A good one for someone from QA: a Mangrove "price check" app. Store staff scan or type a product code and see the price, stock and any active offer. It needs an API, a small database, a React page, tests at three levels, and a pipeline that deploys it. Write a README that explains your test strategy. That README is where your QA background shows.
Using your current job
If you are working in QA now, your best practice ground is the job itself.
- Fix a bug you found. Ask whether you can pick up a small, low-risk one, with a developer reviewing it. One merged pull request on a real product teaches more than a week of exercises.
- Make your automation code reviewable. Ask developers to review your test code the same way they review each other's. Their comments are free mentoring.
- Pair on a feature. Sit with a developer while they build something you will later test. Ask why they chose each step.
Be open with your manager that you want to switch. Many teams would rather grow a developer who already knows the product than hire one who doesn't.
Common traps
- The tutorial loop. Watching or reading without building. The fix: one project, finished.
- Dropping your testing habit. New developers often stop writing tests "to go faster". Keep yours. It is your advantage, not your old job.
- Chasing every framework. One language, one front-end library, one back-end framework, done well, is enough for a first developer role.
- Hiding your background. In interviews, "I spent three years finding the bugs your developers miss" is a strength. Show the test strategy in your project.
After the 16 weeks
The Full-Stack Developer path continues with Application Security for Developers, Scaling Building Blocks and From Engineer to Tech Lead. Take them once you are writing code every day; they make much more sense then. If you would rather stay close to testing, the QA Engineer path and the free Kill the mutants campaign in the QA Lab lead toward quality engineering and test automation roles, which is a strong career in its own right.
The short version: don't start from zero. Start from tests, learn the language properly, finish one project, and let your QA background be the thing that makes you stand out.