Vibe Engines
YouTube
LEARNING PATH · Foundations

From Manual Tester to SDET

For manual QA testers moving into software development engineer in test (SDET) / automation.

Beginner ~2h 45m8 lessons8 steps

A persona-framed path that starts from the test design you already know, adds your first code and automation, and threads through the QA/SDET roadmap and the AI-era QA shift — the honest route from clicking through test cases to engineering the systems that test.

  • Build on the test-design judgment you already have
  • Write your first real code and automate what you used to do by hand
  • Adopt the SDET mindset: build the thing that checks correctness
  • Understand how AI reshapes QA — and where your judgment stays valuable
0 / 8 done · 0%
  1. RoadmapNext up

    QA / SDET Roadmap

    Your destination map — start from the test design you already know.

  2. Challenge

    Fizz Buzz

    Your first code: the classic warm-up, in a runnable editor.

  3. Challenge

    Two Sum

    Level up to real problem-solving in code.

  4. Challenge

    Config Validator

    Automate a real check — build tooling the way an SDET does.

  5. Challenge

    Write a Verifier

    The SDET mindset: build the thing that checks correctness automatically.

  6. Handbook

    The AI-Era QA Engineer

    How AI changes QA — and the judgment that stays yours.

  7. Handbook

    AI-Assisted Interviews

    The 2026 interview: working with AI in the room.

  8. Handbook

    The Resume & Portfolio Handbook

    Present the shift as an engineer — a portfolio of real automation.

How this path works

This path is for manual QA testers and test analysts who want to move into automation and the software development engineer in test (SDET) role. You may already write test cases, file clear bug reports and know which parts of a product tend to break. You do not need to know how to program. You will start from zero in code, in small steps.

An SDET interview usually tests three things. First, whether you can write and read basic code and automate a check. Second, whether you design tests well: coverage, edge cases, risk and what "done" means. Third, whether you can build something that checks correctness automatically and keeps working as the product changes. Increasingly, interviewers also ask how you would test AI-powered features, whose output varies from run to run.

The order protects the strength you already have. You begin at the QA and SDET roadmap, a map of the destination whose first stations cover testing foundations, including version control and CI basics. Then you write your first function, solve a real problem in code, build a small validator the way an SDET builds tooling, and write a verifier, which is the central idea of the job. The last steps cover how AI changes QA, the interview, and presenting your automation work.

What each step gives you

  1. QA / SDET Roadmap

    An 18-station roadmap in three tracks: testing foundations (what to test, unit and integration testing, test design, bug reports, version control and CI basics), automation (UI and API testing, frameworks, pipelines, test data, flaky tests) and advanced quality, including performance, security and testing AI systems. Read it to see which stations you already know and which are new.

  2. Fizz Buzz

    The famous screening warm-up: return a list where multiples of 3 become Fizz, multiples of 5 become Buzz and both become FizzBuzz. The only trap is the order of the divisibility checks. As a tester you already think in cases, so use this to get comfortable with the editor, the run button and hidden tests that tell you which case failed.

  3. Two Sum

    Find the two numbers that add up to a target. A brute-force double loop works but slows down quickly, and a dictionary lookup does it in a single pass. It introduces the habit of thinking about how a solution scales, and it teaches the kind of data-structure reasoning that automation code and coding screens both rely on.

  4. Config Validator

    You implement a function that checks a configuration against rules for type, required keys and allowed values, and returns a sorted list of clear errors. It is the first real tooling exercise: input validation that fails loudly and early. Good practice for writing helpers that make test failures easier to read and for the edge cases a tester naturally thinks of.

  5. Write a Verifier

    Write a verifier that recomputes a score from ground truth, requires the answers to cover exactly the expected tasks, and ignores a number the submitter reports about itself. This is the SDET mindset in one exercise: build the thing that checks correctness so it cannot be fooled. Expect interview questions about assertions that are too weak or too easy to game.

  6. The AI-Era QA Engineer

    Describes what gets cheaper in QA (scripts, selectors, boilerplate cases) and what becomes scarce: test strategy, exploratory judgment and evaluating AI behavior. It gives five ways to work with AI this week, including reviewing generated tests to see whether they test anything. It prepares you for questions about testing non-deterministic features.

  7. AI-Assisted Interviews

    Explains the interview format in which an assistant is allowed and the evaluation shifts to how you decompose a problem, direct the tool and review the output. For an SDET candidate, review is a natural strength. Use the preparation section to rehearse narrating a session where you catch a plausible but incorrect test or code suggestion.

  8. The Resume & Portfolio Handbook

    Shows how an applicant tracking system scores keywords before a person sees your resume, and how to make the human read count. For a tester becoming an SDET, the portfolio is the key part: a small public repository with automated tests, a readable README and a few documented decisions. Rewrite your experience as engineering outcomes, such as defects caught or manual effort removed.

A study plan

  1. Week 1

    Read the QA and SDET Roadmap and mark each station as known, partly known or new. Solve Fizz Buzz in Python or TypeScript, then write the test cases you would design for it by hand, including the edge cases.

  2. Week 2

    Solve Two Sum, then Config Validator. For each, list the test cases you would write before coding, and compare them with the hidden tests. Start the roadmap's version control and CI basics station alongside.

  3. Week 3

    Solve Write a Verifier, then read The AI-Era QA Engineer handbook. Pick a small public website or API and write ten automated checks for it, keeping the code in a repository with a README that explains what each check protects.

  4. Week 4

    Read The AI-Assisted Interviews Handbook and practice narrating a review of generated test code. Then work through the Resume and Portfolio Handbook and rewrite your resume with your repository at the top and results stated as outcomes.

Questions about this path

How do I move from manual testing to automation?

Start by keeping your test-design skill and adding code gradually. Learn one language well enough to write small functions, then automate checks you already run by hand, beginning with stable ones such as API calls. Store the work in a repository so you build version-control habits. Resist trying to automate everything: choose cases that are repeated, high value and stable. The roadmap in this path lists the stations in order, from unit tests through frameworks, pipelines and flaky test handling.

Do I need to be good at programming to become an SDET?

You need to be competent, not brilliant. SDET interviews usually include a coding screen at an easy to medium level, plus questions about test design, frameworks and debugging flaky tests. Comfort with strings, lists, dictionaries and basic complexity covers most of the first round. The harder part is writing maintainable test code that others can read. The challenges in this path start at a warm-up and build toward writing a verifier, which mirrors the actual job.

Will AI replace manual testers and QA engineers?

AI can already draft test scripts and selectors, so routine, repetitive execution is the most exposed work. Test strategy, exploratory testing, understanding risk and judging whether a test actually checks anything are harder to hand over. Testing AI features adds new work, since outputs vary and need evaluation sets rather than fixed assertions. Moving toward engineering and evaluation makes your position stronger, but nobody can promise how any individual role will change.

What should an SDET portfolio contain?

A small public repository is enough if it is well made. Include automated tests for a real or sample application, a README describing what is covered and why, a simple CI configuration that runs the tests, and notes on one flaky test you fixed. If you can add a short evaluation for an AI feature, even better. Reviewers want evidence of judgment: what you chose to test, what you skipped, and how you would maintain the suite as the product changes.

Manual testers already own the thing that’s hardest to teach and hardest to automate: test-design judgment — knowing what to test, what could break, and what "done" means. The move to SDET isn’t abandoning that; it’s adding the code and automation that let you apply it at scale. This path is ordered so you build on your strength instead of starting from zero.

You begin at the destination (the QA/SDET roadmap, which includes a version-control and CI basics station), write your first real code, automate a real check, then internalize the SDET mindset by building a verifier. It finishes on the AI era — where rote test execution automates but test strategy, exploratory judgment, and testing non-deterministic AI systems become more valuable — plus the interview and a portfolio that presents you as the engineer you’re becoming.

← All learning paths