The SDET Skill Stack for the Agentic Era [Testμ 2026]

The Load Test Nobody Ran

He opens with a thought experiment: go back a couple of years, take a magic wand, and pick which parts of your job you wish away and which you magnify. Then he immediately withdraws the framing, because this is not a hypothetical question anymore now that models, coding harnesses and agentic workflows are doing exactly that to the job.

Narrowed to SDETs, the exercise becomes three questions that are the whole talk: what part of your job shrinks, what part magnifies and gets more valuable, and what do you have to do to stretch into something genuinely new. He promises up front to be honest about the first one.

The chatbot story is his anchor, and he tells it without blaming anyone. The team had been careful and had observability on cost and on behaviour. They simply had not thought about load. He also concedes that models and harnesses keep getting better at catching this themselves, and calls that real.

The pattern he draws from it is that the person who catches the gap is almost never the person who knows the most about the models. Neither the team nor the company is named, so this is an anecdote he observed rather than a case study.

That person already has a title, and it is the audience. An SDET is a software engineer who lives in the quality space, owning frameworks, shaping strategy and making sure teams get fast trustworthy feedback when they ship.

He is precise that the new skills sit on top of the old ones rather than beside them, which is the argument against feeling like you are starting over.

Automation As Design

The first column is not what most job descriptions say it is. The skill was never writing test scripts, it was designing the thing that scripts live in: API harnesses, the framework itself.

He frames that as a design job whose real product is other people’s productivity, a job about making other people’s work repeatable, and tells the audience to remember the phrase because it returns in the prompt library section.

The concrete upgrade is depth over breadth: pick one stack and go deep rather than broad.

Then the unglamorous half: go kill your flakiness, and make the framework extensible, where extensible means someone can plug a new test generator into it without rewriting the core.

His justification is a forecast rather than an observation, that in about a year something is going to want to plug into it, so give it a socket. That is his prediction with a specific horizon and no basis offered.

Test Design And Risk

The second column is test design and risk-based thinking, which he calls the most undervalued, including by the people who have it.

Boundary analysis, equivalence classes and state transitions all sit on top of a single judgment call made over and over: what deserves coverage and what does not.

His characterisation is the line the section turns on. That is not technique, it is taste, built from being wrong a lot, and he calls it the scariest thing in AI quality work right now.

The upgrade is to externalise it. Most of the risk model lives in your head, so get it onto paper as a checklist, a matrix or a page in the repo saying these are the high-risk areas, here is why, and here is what we always check.

The AI-specific reason he gives is the strongest argument in the section: a model can read a document, and it cannot read your intuition. Written-down judgment is the raw material for everything in the second half of the talk.

Debugging Past The Symptom

Debugging and systems thinking is his favourite column, and he makes a deliberately aggressive claim about it. The skill is not reading logs, since plenty of people read logs. The skill is refusing to stop at a symptom, so when somebody says a test is flaky, a good SDET asks flaky how before finding the race condition, the shared fixture or the timeout.

He grounds it in his own team’s practice. They run browser testing agents and harnesses, which he thinks every company should have by now, and get constant feedback about what is wrong with theirs.

What has changed is the shape of that feedback. It increasingly arrives as long, confident, AI-generated write-ups, where somebody runs the harness through a coding agent and returns with a detailed explanation of everything wrong with it.

His in-house figure is that 99% of the time the fix is a prompt tweak, with no change to the agent or the harness. That is his estimate about his own team, offered with no sample size or period, and it carries an adverse claim about named commercial coding tools that he states without showing examples.

The upgrade is to make root-cause work systematic rather than heroic. Write down your failure taxonomy, the eight or ten ways things actually break on your system, file every incident under one of them, and notice which bucket is eating your life. Categorise the failure, do not just fix it.

CI/CD As Information

The fourth column is CI/CD and fast feedback, with the emphasis on the second half of the phrase. Pipelines, environments and dashboards are just implementation.

The actual job is delivering the truth about system health to a human fast enough that they can still do something about it. The reframe is that you have been solving an information problem this whole time, not an infrastructure problem.

Because the problem is information, so is the upgrade. Standardise how test runs are tagged, by suite name and stage, which he concedes is boring, high-return work.

Then expose your quality signal somewhere a human actually looks, rather than in a report nobody opens.

His agentic-era justification is about attachment surface. When you eventually want to attach an AI-generated test suite or point an agent at your system, you need a clean surface to attach it to. A tidy pipeline with clear signals is that surface; a pile of ad hoc jobs is not.

Collaboration And Review

Skills five and six are deliberately not columns. Collaboration and quality advocacy are the slab underneath everything, and he admits he almost left advocacy off the map entirely before deciding it was one of the biggest places to get a head start.

The collaboration upgrade is a rhetorical habit. Practise explaining testing decisions as a story with a trade-off in it: not that you found four bugs, but here is what you covered, here is what you deliberately did not, and here is the risk you accepted and why.

His reason is forward-looking and slightly uncomfortable. Soon you will walk into a room to explain a finding an AI produced, to people who are not sure they believe it, and you will need every bit of accumulated trust.

The half he says he almost forgot is reading code you did not write and forming a fast, correct opinion about it. That has been the SDET’s job for a decade, and with the share of unauthored code everyone reviews going up fast, the industry is arriving at a condition SDETs have lived in the whole time.

The upgrade is explicitly not reviewing faster. Once volume goes past what you can actually read, speed stops helping and you just skim more things badly. The skill is risk-based sampling: the same judgment used to decide which paths get a test, pointed at diffs, so some changes get a real read and others get a skim on purpose, with your eyes open.

The Three Things That Shrink

Here he corrects his own framing on the record, saying he has been claiming nothing gets thrown away and that is not completely true. The correction is the honest centre of the talk, and any summary that leaves it out misrepresents him.

Handwriting repetitive tests shrinks. So do manual regression passes, and maintaining a wall of brittle selectors. His verdict on all three is good riddance.

He is blunt about the personal implication rather than softening it. If that is most of your week right now, that part is going away, and he refuses to stand there and pretend otherwise.

What does not shrink is everything else on the map, which he compresses into the talk’s cleanest distinction: the judgment, not the typing.

He restates the foundation before moving on. Four columns on a slab of collaboration and code review, every item on it judgment work, which is precisely why none of it goes away and why he could afford to be honest a moment earlier.

Prompt Engineering For Testing

For each new skill he promises three things: what it is in plain terms, which existing skill it builds on, and a three-step path short enough to start in a week.

The first sits on automation and frameworks, and he defines it tightly because the term has gone mushy. Prompt engineering for testing is using prompts to generate test ideas, test data and checks that are reliable, repeatable and tied to actual risk, and those three words carry the definition.

His disqualifier is direct. Anybody can get a model to write a test and plenty of tools do that, which is a party trick. Getting it to produce the same quality of test on the same area of your system next Tuesday, for a different engineer, is engineering.

The reframe that makes it familiar is that you already know the difference between a pile of test scripts and a framework, meaning versioned, parameterised, reviewed and reused. A prompt library is the same object, and most people’s prompts live in chat history, which is the pile-of-scripts stage.

The three steps are foundations in how models behave, then testing-specific patterns because different jobs want different prompts, and then the one he says matters: ship a small prompt library for your own domain in the repo and review it like code. Ten prompts is his suggested starting point.

Data Curation As Corpus

Data curation and corpus design sits on test design and risk-based thinking, which he calls the tightest fit of the four.

He pre-empts the objection that this is a data science job. Here it means building the set of examples your AI testing runs against: real users, real flows, edge cases, inputs, and critically, labelled examples of good and bad behaviour.

The ownership claim is the sharpest line in the section. Somebody has to decide what bad means for your product specifically, in writing, and that person should be you.

The equivalence he draws is that equivalence partitioning is corpus design. Picking a representative value for a whole class of input is already the same act, and the risk model becomes the labelling schema, with high, medium and low risk as tags on rows. The nouns changed and the thinking did not.

The three steps: mine sources that already exist, since the best corpus material is buried in your own history of being wrong; structure it as input, expected, behaviour, risk tag and severity; then build one narrow data set and use it both to generate tests and to evaluate them.

Model Literacy, Lower Bar

Model understanding builds on debugging, and it is the one he says most people are nervous about and most ready for. He wants the bar lowered: you do not need to train a model, you need to test one.

What is required is enough understanding to reason about failure: how the thing holds context, where it makes things up and why, and how you measure whether it is any good. That is the thing you already do, which is figuring out how it breaks.

The transferred instinct is the one planted in the debugging section. Just as you never accept “it’s flaky” as a root cause, do not accept “it hallucinates” either, because that is a symptom.

The mechanisms underneath it are debuggable: retrieval missed the right document, the context window overflowed and dropped the instruction, temperature was set for creativity on a task that needed determinism, or the prompt was ambiguous and the model picked a reading.

His own worked example is self-deprecating. He hit a small UI bug in his own code where he admits he was being lazy, multiple coding harnesses could not fix it, and he burned prompts and tokens going nowhere. The cause was the context window overflowing and dropping his instructions, and knowing the mechanism gave him two options rather than one: adjust and hit the tactical goal, or decide the problem is better solved another way. The second option only exists if you know the mechanism.

The syllabus is short, covering tokens, temperature, determinism versus randomness, retrieval and evaluation metrics, which he estimates at a weekend. The testing patterns then map onto old ones: correctness, hallucination and safety detection, guardrail validation, and adversarial input, which he calls negative testing wearing a new hat.

Observability For Agents

The last new skill builds on CI/CD, and the problem it solves is one the audience has solved before, at two in the morning, on an incident.

When an agent does something on your system you need to answer three questions afterwards: what did it actually do, why did it choose that path, and did it stay inside the lines you drew.

The material is familiar, being logs, traces and metrics, but pointed at decisions instead of requests. His verdict if you cannot reconstruct that is memorable: you do not have a testing agent, you have a rumour.

He argues the audience has already built this, having spent years making opaque automated processes legible to a tired human. What changes is only the payload, since the number on the wall used to be pass rate and is now a sequence of decisions, while the guiding question is unchanged: what would I need to see right now to know whether to trust this?

The three steps: capture prompts, tool calls, decisions, state transitions and errors; make it viewable as traces and timelines linking what the agent did to what happened, because a wall of JSON is not observability; then instrument one simple agent, make it misbehave on purpose, and see whether your traces explain why. If they do not, that is the finding.

Evals And Quality Architecture

He tells the audience to stop treating the four new skills as four separate things. Corpus comes from data curation, grader from model literacy, harness from prompt engineering on top of automation, and scoreboard from observability. Put all four together and you get one artifact.

The job is the same as always: define expected behaviour, run it, get a verdict. Exactly one thing changes, which is the assertion. Exact match does not work when the output is different every run and still correct, so you swap it for a grader, a rubric or a model judging the output, and check properties instead of values.

The three steps end on the one he says nobody warns you about. Pick one AI behaviour and write a grader for it, run it in CI on every change, and watch what it costs, because an eval suite is an API call running on every commit and it produces a bill. He adds that almost nobody owns that number, an industry-wide claim he offers without a source.

The roof is not a fifth skill but a job. Becoming a quality architect is the move from writing tests to designing and governing the systems that produce quality: policies, guardrails, review loops and escalation paths. It sits on the collaboration and advocacy slab on purpose, because governance is an organisational act and you cannot govern something people do not trust you about.

In practice governance reduces to three questions. What are agents allowed to do in staging versus production, and he argues those should not be the same answer. Who reviews what, when does a human inspect AI-generated tests, and when can a human override an agent’s decision. And what risk threshold forces a human into the loop.

His closing instruction is anti-framework. Do not go build a governance framework; write the rules for one workflow, add one real check such as manual review above a risk threshold, then pick one column and finish its three-step path, because you learn more from finishing one than from reading about all four.

Q & A Session

Four audience questions closed the session, read out by the host, who is not named in the recording.

• How should CI/CD pipelines change when AI agents are writing and deploying code?

  Adeel Mansoor: Start with something you would do even before agents: lower the risk on your highest-priority features. If you have a suite marked high priority or smoke, run it as early as possible and make that context available to the coding harnesses up front. In a way pipelines do not change much. What changes is speed and timing, so you run sooner and get feedback sooner. His conclusion is deliberately deflationary, and he does not address deployment gating, approvals or rollback for agent-authored code, despite deploying being in the question.

• How might the SDET skill stack evolve into 2027 and beyond?

  Adeel Mansoor: I am not somebody who spends a lot of time thinking two years out, because things are changing so fast, and the biggest takeaway is that they will change in ways nobody can anticipate. Be flexible, keep learning, and stay aligned with the business goals of your team or company. That is an explicit non-answer on the skill stack itself, and no specific skill, tool or trend is predicted.

• How do we enforce security policies at the tool and infrastructure level rather than relying only on system prompts?

  Adeel Mansoor: I may not be reading the question correctly. Security testing is cheap enough now to build into the pipeline even for internal tools, most companies had started before the AI wave, and the expensive review software used to produce noise that was hard to separate from signal. Run your security policy on PR commits, before a human even looks. He hedges that caveat twice, and what he answers is shift-left scanning rather than the infrastructure-versus-system-prompt distinction the question asked about.

• I am an SDET with 15-plus years of experience. What should I do to stay competitive?

  Adeel Mansoor: One answer: get really comfortable with evals. Whether you are building AI tools for external customers, internal customers or internal use, all of it relies on evals. Where you would once demonstrate Selenium or Playwright expertise in browser automation, evals are the equivalent thing to show a recruiter or hiring manager. Skill up on everything in the talk, but focus on its output.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.