So you want to be an SDET

Maybe you’ve been on a manual QA team for a few years and you’re watching the automation engineers get the promotions, the conference invites, and the nicer laptops. Maybe you’re a junior dev who got assigned to “the test framework project” and you’re starting to wonder if this is your thing. Maybe a recruiter slid into your inbox with the title and a salary band that made your eyes go wide.

Whatever brought you here — congratulations. It’s one of the best jobs in software. I’ve been doing it for fourteen years and I still think it’s the best seat in the building.

But before you run off to sign up for a Java course, I want to give you the one piece of advice I wish someone had hammered into my head when I started:

Don’t become a software engineer who happens to test. Become a tester who happens to code.

Those sound like the same sentence. They are not the same sentence. They are, in fact, the difference between a great career and a forgettable one — and getting them mixed up is the most common mistake I see in our field.

The trap

Here’s a pattern I’ve seen play out more than once.

A solid QA engineer decides they want to “level up.” They start learning Java or Python or TypeScript. They build their first Selenium framework, then their first Playwright framework. They start hanging out in the developers’ Slack channel. They commit code. They get a code review from a senior engineer. They feel a rush — finally, real engineering. Real respect.

And somewhere in there, slowly, they stop doing the things that made them good in the first place.

They stop poking at the edges of the feature. They stop asking “what happens if I do this in a weird order?” They stop sitting with the product manager and asking dumb questions about what the user is actually trying to accomplish. They stop thinking like an attacker. They stop thinking like a confused first-time user. They stop thinking like a tester.

By the time they’ve got the title — Software Development Engineer in Test — they’re a mediocre developer with a fading testing instinct, and the company has lost the thing they were actually paying for.

This is the trap. It is everywhere. It is so common that the role itself has been quietly drifting toward “junior developer who happens to be assigned to the QA team.”

The thesis

The job title is Software Development Engineer in Test. Read it again. The noun is Test. Everything before it is modifying that noun.

You are a tester. You are a tester who can write production-grade code. You are a tester who can read a pull request and tell the developer that their unit test isn’t actually testing what they think it’s testing. You are a tester who can build a framework, run it in CI, debug a race condition in the test runner, and — when none of that matters because the feature is fundamentally broken in a way no automated test would catch — open the app, click around for ten minutes, and find the bug.

Coding is the multiplier. Testing is the thing being multiplied. If the thing being multiplied is zero, the multiplier doesn’t matter.

What not to lose

If you take nothing else from this post, take this list. These are the things that will atrophy if you let them, and these are what make you valuable:

Curiosity. The reflex to wonder what would happen if — and then to actually go find out. Devs build the happy path. Testers wonder what’s off the path.
Question-asking. “What does this feature do?” “Who is it for?” “What happens when it fails?” “What happens when the network fails?” “Have we shown this to a real user?” The dumb questions are almost always the important ones.
The “how can I break it” mentality. Not adversarial — protective. Every bug you find before a customer does is a bug that doesn’t cost the company a Slack incident at 11 PM. This instinct is gold. It does not exist by default in most engineers. Guard it like a security clearance.
Empathy for the user. Devs build features. Testers think about the human on the other end of the feature, who has not read the design doc, does not know what the field is for, and is going to do something nobody anticipated.

You will not lose any of these by learning to code. You will lose them by forgetting to use them once you can code, because the dopamine hit of merging a pull request is bigger than the dopamine hit of filing a bug report.

Set a reminder if you have to. Once a week, ask: am I still testing the thing, or am I just maintaining the framework that tests the thing?

What to add

Now the engineering side. The skills that actually move the needle, in roughly the order I’d learn them:

Clean, readable code. Naming, small functions, single responsibility. A test that nobody can read is a test that gets deleted in two years when nobody remembers what it was for.
Object-oriented principles. Inheritance, composition, interfaces. You don’t need to write the next Spring Framework, but you need to be able to design a test framework that doesn’t collapse under its own weight in eighteen months.
Unit testing — and I mean real unit testing. This is the big one, and the one most underrated by SDETs trying to level up. If you understand unit tests deeply — what makes one good, what makes one a smell, when mocking helps and when it lies — you become something rare: a tester who can sit in a code review and tell a developer their test is bad, and explain why. That is a superpower. Most SDETs never get there.
Version control and CI/CD literacy. You don’t have to be a build engineer. You do have to read a .gitlab-ci.yml or GitHub Actions workflow without panicking, and know roughly where your pipeline is wasting time.
Debugging. Not just “the test failed, here’s a screenshot.” Why did it fail? Was the failure deterministic? Was it the test, the framework, the application, the network, or the moon? Good debugging is half the job.

What’s not on the list: building a full web application, mastering a frontend framework, learning a backend framework deeply enough to architect a service. You are allowed to learn these things. They are not the job. Don’t let them eat the job.

The AI angle

Here’s the part that, three years ago, I would not have written.

The world does not need more developers right now. AI is going to write a staggering amount of the code that used to take a junior engineer a week. The bottleneck on shipping software is shifting, and it’s shifting toward people who can answer one question with confidence: is this actually correct?

That question — at every level, from a unit test to a production deployment — is a testing question. It always was. We just used to be able to mostly muddle through with manual review and a few integration tests, because human-written code came at human speed. Now it doesn’t.

The world needs more testers. People who think critically, ask hard questions, and can sniff out the cases nobody thought of. And if those testers can also code — which means they can build the systems that test other systems at machine scale — that’s not just a good career. That’s a superpower with a superpower bolted on top.

Don’t trade in the first one to get the second. Stack them.