I want to be straight with you about something: I don’t have this fully figured out either.
Forty years in, and I’m still relearning parts of my own profession. Not because what I knew was wrong. Because the ground moved. If you’re feeling that same shift under something you’re genuinely good at, I’m not writing this from the other side of it, telling you what to do. I’m writing it from inside it, sharing what I’m noticing as I go.
Some people will tell you newcomers have the advantage right now, because they have nothing to unlearn. I understand why that story gets told. It’s not the whole story, and I want to spend this page on the part that usually gets left out: what you already have that they don’t, and what I actually think is worth your time to add to it.
— Hung Nguyen, Creator of STeP at SOH
What’s Actually Changed
Here’s a small, specific thing that happened to me. Back in the 90s, I authored and co-authored a couple of testing books. They did well, for their time. Most of what’s in them doesn’t apply anymore. Not because they were wrong. Because the work changed underneath them.
I tell you that not to be dramatic about it. I tell you because if something I built my name on can go quiet, I’m not going to pretend your years of experience are somehow exempt from the same thing happening in smaller ways, all the time. The difference is, nobody’s asking you to throw out the book. Just to keep writing new chapters.
What’s actually shifted isn’t the value of catching bugs, planning coverage, or knowing when something’s off. That instinct is still the job. What’s shifted is where your time goes, and what’s now generating a lot of the raw material you used to produce by hand. Test cases, first drafts of automation scripts, exploratory suggestions. AI can throw a lot of that at you fast now.
So the question that used to be simply "can I find the bug" has quietly become three questions at once. Can I tell whether what AI just handed me is actually right. Can I tell whether it’s missing something a human would have caught. And, less talked about but just as real: how do I actually talk to AI well enough to get real value out of it, without burning half my day and half my token budget figuring out the right way to ask.
That last one isn’t a small skill. It’s becoming its own kind of literacy.
Your Experience Isn’t the Liability
I keep hearing a version of the same fear, from testers who’ve been doing this for years: if AI can generate tests and write automation, what’s left for someone like me?
Here’s what I actually think is left, and it’s more than one thing.
AI is genuinely good, and fast, at producing outputs from data and patterns. That’s not in question. What it doesn’t bring on its own is creative and critical thinking, the kind that comes from having been wrong before and remembering why. That’s what lets you actually lead and work alongside AI instead of just consuming what it hands you, and it’s the difference between AI as a multiplier on your output and AI as a black box you’re hoping is right.
And then there’s judgment, which is related but not the same thing. Creative thinking is what lets you direct AI toward the right problem in the first place. Judgment is what lets you look at what it produced and know, really know, whether it’s accurate, trustworthy, and safe to ship. You need both, and both are built from years of doing this work, not from a course completion certificate.
The bottleneck in this profession right now isn’t code generation. It’s evaluation, verification, direction, and judgment, four things that don’t come from being AI-native by default. They come from time. You’re not behind. You’re sitting on the thing this moment actually needs more of.
A Day That’s Already Yours, Just Shifted
You already know what your day looks like. I’m not going to describe your job back to you. But here’s what I think is quietly different now, even if it hasn’t been named yet where you work:
Morning
Morning stand-ups increasingly start with what an automated suite already caught overnight, and your first real decision of the day is what’s actually worth your attention out of that pile, not what to test first.
Midday
Midday work still has structured cases and still has exploratory testing, the kind no AI can decide to do for you. But more of it now includes reviewing AI-generated test code or AI-suggested cases before you trust them, which is a different mental motion than writing your own from scratch.
Afternoon
Afternoons still have the bug you dig into with a developer. Increasingly, they also have a conversation about whether the AI-assisted tooling your team adopted six months ago is actually pulling its weight.
All Day
And running underneath all of it, not confined to any one part of the day: an ongoing, close working relationship with your dev team, jointly hunting for ways to speed up testing itself, because the volume of code and features coming out of developers and coding agents now moves faster than most testing processes were ever built to handle. Keeping pace with that isn’t a one-time project. It’s becoming a permanent part of the job.
None of this replaced your job. It moved where your attention goes inside it.
The Traps I’ve Watched Experienced Testers Fall Into
I’ve sat through more training than I can count over four decades, and most of it fell into the same handful of holes. You’ve probably hit at least one of these yourself:
Tactical and tool based.
“Here’s how to click this button in this tool.” You forget it in six months because it never taught you to think, just to follow.
Too broad.
Generic platforms that treat testing as one topic among five hundred, with none of the depth that actually changes how you work.
Too certification centric.
Built to hand you a credential, not the judgment the credential was supposed to represent in the first place.
Treating learning as a destination.
This might be the most common trap of all, and the easiest to fall into with good intentions. You finish a course, get the certificate, and treat the learning as done. What you actually walk away with here is meant to be foundational, real skill and real knowledge, but more important than either is the capacity it gives you to keep following and adapting as AI and this profession keep changing, because they’re not going to stop. Your journey doesn’t end when a course does. I’m hoping to be a companion on that journey, not a finish line.
I built STeP specifically to avoid the first three. The fourth one is on both of us to keep avoiding, together, after you finish here.
Where You Actually Start
Here’s the practical part, because I know that’s what you actually came for.
The foundation course in STeP, the one that covers testing fundamentals, is built to be required for people new to the field. For you, it’s optional. A refresher, not a requirement. If you want to skim it to confirm nothing’s changed underneath you, it’s there. If you’d rather skip straight past it, that’s a real, supported choice, not a corner being cut.
What isn’t optional, for anyone, is the AI in testing track. This is where I’d point you first. I genuinely think it stopped being a specialization and became a baseline skill, the same way basic scripting stopped being optional a decade ago.
API testing and test automation engineering come after that, and here I want to correct something people sometimes assume: this isn’t an "if you’re headed toward automation roles" kind of optional. It’s a lower priority than AI in Testing, not a skippable one. You don’t need to become an SDET. In this era, it’s natural to use AI to help build and execute tests automatically, and increasingly, that’s just how the work gets done. But you need to understand how automation actually works well enough to prescribe the right tasks to AI and review what it generates with real judgment, not just faith. That understanding, not SDET-level depth, is what keeps you in the game.
You don’t start at square one. You start wherever the actual gap is, and you don’t skip the parts that keep you able to check AI’s work.
The AI Concepts Worth Actually Understanding
I’m not going to hand you a vocabulary list. You’ve been in this field long enough to know what regression testing and exploratory testing mean. What’s actually new, even for people who’ve been doing this a long time, is understanding how the AI systems you’re now working alongside actually work under the hood. Not to become an AI engineer. To stop treating the thing you’re testing, and using, like a black box.
How the model actually works.
What an LLM is and how it generates output in the first place, and something most people never learn even after using these tools daily: the context window, meaning how much the model can actually hold in mind at once, and why long AI conversations start forgetting earlier instructions or quietly drifting off track. If you’ve ever had an AI tool get worse the longer a conversation ran, that’s usually why.
Talking to it well.
Prompt engineering and prompt patterns, the actual structures behind getting reliable results instead of guessing. The difference between fine-tuning and training, since people use these words interchangeably and they’re not the same thing. And understanding why AI output isn’t deterministic in the first place, meaning the same prompt can give you a different answer twice, which comes down to the combination of the underlying model, the system prompt shaping it, and the code logic wrapping it all together. Once you understand that combination, “AI gave a different answer this time” stops being mysterious and starts being something you can actually reason about.
What it can reach beyond itself.
RAG, which is how a model gets grounded in real, specific source material instead of just its general training. MCP, the protocol that lets AI tools actually connect to and use other tools and systems. Tool use itself, which is the underlying capability of a model deciding to call something at all, separate from the protocol connecting it. And what an “agent” actually is, since the word gets thrown around a lot: it’s really just a model, plus tools, plus a loop that keeps going until a task is done. Not magic. Just mechanics worth knowing.
Why any of this matters for the work.
Agent Skills, a packaged, reusable set of instructions an AI can invoke instead of someone re-explaining a task every time, increasingly portable across tools. And grounding, the practice of tying an AI’s output back to verified source data, which connects directly to RAG and directly to catching hallucinations before they become a bug you missed.
You don’t need to master all of this before you start. You need to know it exists, and STeP is where you’ll actually build it out properly.
Why I’m Telling You This
I’m not going to tell you that nothing happens if you don’t adapt. Something does. The gap between testers who’ve picked up AI literacy and those who haven’t is real, and it’s not closing on its own.
But I’m also not going to manufacture urgency you don’t need. You’ve survived more shifts in this field than most people even notice happened. You’ll survive this one too. The only real question is whether you spend the next year catching up on your own, piecing it together from scattered sources, or whether some of that time gets handed to you already organized, by someone who’s walking the same road.
That’s the only thing I’m actually offering. Not a credential. Not a guarantee. Just what I’ve been figuring out, organized enough to save you some of the time it took me.
Most of the experienced testers I’ve worked with over the years didn’t need to be convinced this profession mattered. They needed a way back in that respected what they’d already built. That’s what I tried to build here.
— Hung Nguyen, Creator, SOH-STeP
