--- title: "Manual to Automation Testing in Six Months: Skip the Tutorial Loop" author: "Harry" published: 2026-10-31T04:46:54.704Z updated: 2026-10-31T05:06:51.251Z category: "Career & Teams" tags: ["qa-career-path"] canonical: "https://fxblog.dev/posts/manual-to-automation-testing" --- # Manual to Automation Testing in Six Months: Skip the Tutorial Loop ## Key takeaways - The first language to learn for test automation is the one your team's suite already uses, because your first real test will live there. - After one Getting Started guide, automate three flows from your own product's regression instead of more tutorials. - A stable automated test waits for the state it needs, never for a fixed time, and uses user-facing locators. - The best first pull request to a team's suite is one small test for a bug you found yourself; a 30-line PR gets reviewed this week. - At about five hours a week, the plan reaches a merged PR in month three and an owned part of the suite by month six. > **TL;DR** Testers moving into automation rarely stall because coding is hard. They learn in the wrong order (a framework before a language, a tutorial app, a private repo nobody reviews) and finish a fourth course instead of a first real test. Manual to automation testing takes about six months at five hours a week: your team's language, three flows from your product, a small merged PR. > > **Do this:** Message your SDET or test lead today and ask for one small, real ticket: a missing check, a flaky test, or a test for a bug you found. [Part 2](02-first-90-days-qa-engineer.md) ended at week 6, with an automation ticket to pick up, a FieldFlow suite of 300 Selenium scripts about 30% flaky, and a manual regression of 7 tester-days. Which language first, and what should the first pull request be? The usual route: a course, another course, a framework tutorial on a demo shop, a private repo. Months later the team's suite still has nothing with your name on it. **QA Career Path, in seven parts:** 1. The QA Career Path: Map Yourself by Scope, Not by Title 2. New QA Engineer? Test the Risk, Not the Ticket 3. **Manual to Automation Testing in Six Months: Skip the Tutorial Loop** (you are here) 4. Senior QA: Depth Everywhere Is Depth Nowhere 5. After Senior QA: Lead the Release or Own the Platform? 6. QA Manager to Head of QA: The Escape Bill That Wins Budget 7. Will AI Replace Testers? Make Your Judgment the Evidence ## Learn the language your suite already uses Pick the language your team's suite is written in. That rule beats every "best language for testers" debate: your first real test will live there, reviewed by people who know it. With no suite yet: TypeScript or JavaScript for web products, Python for API and data-heavy testing, Java or C# where the backend already is. Learn one properly first, which for a tester means: - variables, functions, conditions, loops, lists and maps - reading JSON, async/await, a package manager, a stack trace - Git alongside it: branch, commit, push, open a merge request, fix a simple conflict ## Automate three flows from your own regression Do the framework's Getting Started once, then stop doing tutorials. At FieldFlow (fictional, like its numbers), the first three: 1. Log in as a dispatcher and check the planner loads: your smoke test. 2. Create a job, assign it, and check it appears on the engineer's list. 3. Call the invoice API and check the rounding and VAT, with the rounding cases from part 2 as its data. It will teach you more than the UI tests. Wait for a state, never a fixed time. The repo's most common bad test, and its repair: ```js // flaky: hopes the invoice list has loaded after 3 seconds await page.click('#save'); await sleep(3000); expect(await rows()).toHaveLength(3); // stable: waits for the condition itself, fails fast with a reason await page.getByRole('button', { name: 'Save' }).click(); await expect(page.locator('.invoice-row')).toHaveCount(3, { timeout: 10_000 }); ``` > **Tip** > > Then break the feature on purpose, or change the expected value, and watch the test fail. A test you have never seen fail is a test you don't understand. ## Make the first PR a test for a bug you found Most self-learners skip this step. It is the one that changes your job title. A private repo proves you can follow a tutorial; a merged PR proves you can work in a team's codebase. ![A first pull request: a bug you found becomes one small reviewed test that runs in CI and merges](https://fxblog.dev/media/01a19047-ec26-7207-93b5-2e92dd8f97c7/1600) _Small, reviewed, run in CI: then it counts_ You know that bug better than anyone. Keep it to one test and one helper at most: a 30-line PR gets reviewed this week, a 500-line one waits a month. The same review comments usually stop after three PRs. ## Six months, one thing per month | Month | Focus | Done when | | ----- | ------------------------- | -------------------------------------------------------------------------- | | 1 | Language and Git | A 50-line script calls your API and prints a field | | 2 | Framework on your product | Three flows from your own regression run locally and fail when they should | | 3 | First PR | One test merged and running in CI | | 4 | Regular PRs | Four merged; you read a red run as product, test or environment | | 5 | Fix, don't add | Two flaky tests fixed properly; one review of others' tests | | 6 | Own an area | One part of the suite is yours: green, reviewed, reported | Ask for some of those hours at work: "learn in your spare time" is not a training plan. > **Warning** > > If an AI assistant writes the test and you can't explain what it asserts, you have committed a liability. Keep doing exploratory sessions too: your next test ideas come from there. ## Try it ```text I'm learning automation in and want my first PR in our suite. Could you point me at one small ticket: a missing check, a flaky test, or a test for bug that I found? I'll keep it under 50 lines and run it in CI before asking for review. ``` Which skills to learn, in which order: **The QA Skills Path for 2026: What to Learn, in What Order**. By month 6 you own FieldFlow's smoke suite. Then R25 lands with five items and 6 tester-days before code freeze. Last quarter 11 bugs escaped, 3 in invoice totals. Where should the depth go? Part 4, **Senior QA: Depth Everywhere Is Depth Nowhere**, decides it with a risk table. ## Read this with your AI ```text Read the post "Manual to Automation Testing in Six Months: Skip the Tutorial Loop". 1. Summarise it in 5 bullets for a manual tester with 5 hours a week. 2. Ask me 3 questions to check I understood; wait, then correct me. 3. Ask me about my product, then pick the three flows I should automate first. ``` > **Success** > > You have a month-by-month route from manual testing to owning part of a suite. Next: **Senior QA: Depth Everywhere Is Depth Nowhere**. ## FAQ ### Which programming language should a manual tester learn first? The one your team's test suite uses. With no suite, TypeScript or JavaScript suits web products, Python suits API and data-heavy testing, and Java or C# suits companies whose backend and frameworks are already there. ### How long does it take to move from manual testing to automation? The plan in the source takes about six months at five hours a week: language and Git in month one, a framework on your own product in month two, a first merged PR in month three, and ownership of a part of the suite by month six. ### Should I stop manual testing once I can automate? No. Exploratory sessions are where your next test ideas come from, and a good automation engineer is a good tester who can also write code.