From Manual QA to SDET: How to Make the Move

The job listings that used to read “Manual QA” or “QA Analyst” read “SDET” now, short for software development engineer in test, usually with a line about AI tooling tucked into the requirements. The title moved toward engineering. The work underneath it moved less than the title makes it look.

I made this move myself. I started in manual testing and went into automation, and the foundation I built by hand is the same one the new version of the job runs on. The years you spend learning where software breaks are not wasted by the tools. They are what the tools need pointed at them.

The honest part is that there is real work to add on top. The good news is that you add it where you are, one piece at a time. No six-month bootcamp, no quitting your job.

What carries over, and why it matters more now

The most valuable thing you bring as a tester is not the ability to execute a test case. It is the ability to look at a feature and see where it is likely to break. Knowing which areas carry the most risk, which scenarios are worth running first, and what a release should never ship without, is judgement you have built one bug at a time. That judgement does not transfer away as the tools change. It becomes more important, because the tools now generate test cases faster than any human can read them, and someone still has to decide which of those cases are worth keeping.

The rest of the fundamentals carry over the same way. Reading requirements properly before you test against them. Putting the highest-risk features at the front of the queue. Writing a defect report clear enough that a developer can reproduce and fix it without booking a meeting to ask you what you meant. None of that is being automated. If anything, the speed of AI tooling is what makes these fundamentals the difference between a team that ships quickly and safely and a team that ships quickly and breaks things in front of customers.

This is not just my read on it. The 2025 DORA report found that 90% of developers now use AI at work, and that without strong automated testing and fast feedback loops underneath it, all that extra change just means more instability. It is the reason QA is the control layer for AI-assisted development, and the reason your career sits on solid ground while the titles change around it.

The faster code gets written, the more the quality work matters, and the quality work is yours.

The change is less a replacement than a re-pointing of the same skills. Here is what the shift actually looks like, before and after.

Before the shift	After the shift
Execute test cases by hand	Decide which generated cases are worth keeping
Write defect reports a developer can act on	Same, and the speed of AI makes them matter more
Test against requirements you read carefully	Same reading skill, now also reading test code for substance
Run the highest-risk flows first	Same risk judgement, now aimed at the tool’s output too
Find bugs by clicking through the product	Find bugs the generated suite quietly fails to catch

What you actually need to add

There are three additions that take a manual tester into an AI-augmented engineering role. None of them require you to become a full-time application developer, and two of them are really your existing testing skills applied to code.

The first is the ability to read and reason about code. You do not need to write a framework from scratch in week one, but you do need to open a test, understand what it asserts, and judge whether that assertion actually means anything. This matters more than it used to because a lot of your test code will now be generated for you, and a generated test that looks correct can quietly check nothing at all. I have seen plenty that fill the screen, go green every time, and would pass even if the feature were completely broken. The skill of reading a test for substance is the modern version of writing it by hand, and it leans on the same understanding of the framework underneath.

The second is real fluency in one automation framework and the language it runs on. Not five frameworks at a surface level, but one understood properly: how it finds elements, how it waits, why a test goes flaky, and how to structure code with patterns like the page object model so the suite survives contact with a changing application. For web automation that usually means JavaScript or TypeScript with a framework like Playwright or Cypress. Locator strategy, atomic tests, and clean setup and teardown of data are the same habits that have always separated a maintainable suite from a fragile one. If you are weighing up which framework to commit to, I have written a full comparison of Playwright, Cypress, and Selenium that walks through how each one actually behaves.

The third is knowing how to direct AI tooling and, just as importantly, how to review what it gives back. Working well with an AI testing tool is closer to writing a sharp test plan than to writing code. You give it clear context about what should be tested and where the risk lives, and then you treat everything it produces with informed suspicion. The engineers who get the most out of these tools are the ones who already know what good looks like, because that is the only way to tell when the tool has missed something.

Here is how those pieces sit on top of what you already have.

Reading a test for substance, in practice

This is the skill that gets least attention and matters most. An AI tool will happily hand you a test that looks thorough, and your job is to decide whether it earns its place in the suite. The traps are consistent:

• A name that tells you nothing. Something like “login works” is useless when it fails at 2am and you cannot tell what actually broke.
• An assertion that checks too little. A test that only confirms the URL changed will still pass when a broken page sits on the right path.
• No negative case. It proves the happy path and nothing about what should be rejected.
• No real-user check. It never confirms the user actually sees what a real user would see.

Reading code well enough to spot what is missing is a testing skill before it is a coding skill, and you do not write a line from a blank file to do it. I walk through the full before-and-after of a weak generated test, and a checklist for grading one, in how to review AI-generated automated tests.

A practical path you can follow

If you are starting this transition, here is the sequence I would follow. It builds on what you already do, and the order matters.

1. Keep sharpening your testing fundamentals. Test design, risk-based prioritisation, exploratory testing, and clear defect reporting are your foundation and your edge. Do not let them slip while you learn the technical pieces; they are the part the tools cannot do.
2. Learn enough of one language to read and change code with confidence. Pick the language your team already uses so the skill pays off immediately. You are aiming for fluency in reading, then small edits, not for building applications.
3. Learn one automation framework properly. Understand its waiting, its locators, and how it reports failures before you touch anything else. One framework you genuinely know beats three you can copy and paste from.
4. Learn how your tests run in the pipeline. Where they execute, what happens when one fails on a pull request, and how testing fits into the team’s delivery. You do not need to be a build engineer, but you need to know where your work lives and how it gates a release.
5. Learn to drive AI testing tools and to audit their output. Treat every generated test as work from a fast but inexperienced contributor: quick, useful, and in need of a careful review before it goes anywhere near your suite.

Only steps two and five are genuinely new, and both grow straight out of testing skills you already have. If you want to see where this sequence sits in a longer career, the QA career roadmap lays out how the skills stack as you grow. Here is the same path as a progression, so you can see where you are and what comes next.

The single exercise that teaches the most

If you only do one thing this month, do this. Take one real feature in your product and automate an end-to-end test of it by hand, looking up whatever you need as you go. Then ask an AI tool to generate the test for the same feature, and compare the two carefully, side by side. As you compare, ask:

• Where did the tool do something genuinely well?
• Where did it write an assertion that does not really check anything, like a test that only confirms the URL changed?
• Where did it skip the edge cases and the negative paths entirely?

Keep the comparison somewhere you can see both columns at once. This is the sheet I use, copy it and fill it in:

COMPARE YOUR TEST TO THE AI'S
Feature under test:  ______________________________
Framework:           ______________________________

                              | Mine   | AI tool
------------------------------|--------|--------
Steps actually covered        |        |
Assertions that mean something |       |
Negative / edge cases         |        |
Real-user check (sees what a  |        |
  real user would see)        |        |

Where the tool did well:            ___________________
Where an assertion checked nothing: ___________________
What it skipped (edges, negatives): ___________________
Verdict on the AI test:  keep / rewrite / delete

That comparison forces you to apply your testing judgement to the tool’s output, which is precisely the skill the new role is built on. Do it a few times and the mental shift happens on its own. You stop seeing AI as the thing replacing you and start seeing it as a fast contributor that needs direction and review. Directing that work, checking it properly, and catching what it misses is the job now. If you want to take the reviewing skill further once you are comfortable, working with coding agents as a QA engineer goes deep on keeping control when the agent is writing more than just tests.

An honest note on the transition

I am not going to pretend this shift is effortless, or that everyone will enjoy every part of it. Some people came to testing precisely because they did not want to write code, and watching the role tilt toward engineering is a real adjustment, not a small one. There are still roles that lean hard on exploratory testing and deep domain knowledge, especially in regulated and safety-critical products, and those skills remain genuinely in demand. But even those roles increasingly expect you to be comfortable around code and around AI tooling. The narrow position of doing only manual testing, with nothing technical attached, is the part that is shrinking, and you are better off hearing that plainly and planning for it than being caught out by it in a year.

The framing I keep coming back to is this: a test automation engineer is a hybrid role that needs the mindset of a tester and the skillset of a developer. You already have the harder half. The mindset, the instinct for where things break, the patience to chase a defect to its root, takes years to build and cannot be generated on demand. The skillset half is learnable, step by step, on top of what you already do every day.

It helps to know what you are pointing the tools at. AI is uneven:

• Strong at the data work. Checking contracts and integrations and combing through logs to spot a backend not returning what it should.
• Weak where the call is hardest. Seeing that a UI is visually wrong, testing a real end-to-end flow, exploring, and judging the risk.

Hand it the analysis; keep the judgment, the visual sense, and the decision to ship for yourself.

When I moved from manual testing into automation, I did not start with anything fancy. My first automation was in Nightwatch.js on Node, then WebdriverIO became my main framework for years, with Selenium and Java on other projects. What I actually learned first was not the framework at all. It was how to find a locator that does not break the moment the design changes, and how to make a test wait for the app instead of guessing at a number of seconds. Those two things decide whether a suite is trustworthy, and they carried across every tool I picked up after. The frameworks changed; those fundamentals did not.

I came to this work almost by accident. I started as an intern in 2015 while I was still at university, having originally wanted to be a teacher, and more than a decade later the part that has held up is the habit of learning the next thing on purpose, not any single tool. The transition is really that plain and that demanding: not a bootcamp, but the discipline of adding one piece at a time on top of what you already do.

You do not have to do this overnight. Start with the foundation you already have, add one piece at a time in the order above, and point the tools at the right problems while catching what they get wrong. That has always been your job. The tools just made it more valuable.