Skip to content
Back to Blog

The QA Engineer in the Agentic Era: From Writing Tests to Designing Evals

AI Transformation Lead
  • AIDLC
  • QA
  • Testing
  • Evals
  • Agentic
  • Software Lifecycle

Deterministic test suites cannot judge probabilistic systems, so the QA engineer's job moved from asserting exact outputs to designing evals. When the same prompt can return two correct answers, a string assertion fails good responses and passes bad ones; the new craft is grading behaviour against a golden reference.

Abstract monochrome visualization of an evaluation gate judging probabilistic outputs against a golden reference set

QA had a clear contract with the codebase. Given this input, assert that output. Cover the edge cases, automate the regression suite, and a green build meant the behaviour you tested still held.

That contract assumes determinism. Agentic systems break it. Ask an agent the same question twice and you may get two different, both-correct answers. A test that asserts an exact string now fails on a perfectly good response, and a test that asserts nothing meaningful passes on a bad one.

From assertions to evals

In the AIDLC method, this is the Eval phase, and it is where QA's leverage exploded. Instead of asserting exact outputs, the QA engineer designs evals: golden datasets of input-and-acceptable-output pairs, rubric-based scoring, and LLM-as-judge suites that grade whether a response stays inside the boundary the spec defined.

This is harder and more valuable than writing assertions. Deciding what "good enough" means for a probabilistic system, encoding it so a machine can grade it, and keeping the dataset honest as the product evolves is a senior discipline. It is the difference between a system that ships confidently and one that regresses silently.

The new gate

Evals are not a phase you run at the end. In AIDLC they run on every change, the same way unit tests used to, gating each diff the agent generates. A behavioural regression that would have reached a user gets caught in CI instead. The QA engineer owns that gate, and owning it makes them one of the highest-leverage people on the team.

They also test the agent's decisions, not just its output. Did it call the right tool, in the right order, and stop when it had enough information? Those are the failures that matter in agentic systems, and catching them is the new craft.

If your team ships agent features with no eval suite, you are running probabilistic software with a deterministic safety net that no longer fits. The mismatch is where your incidents come from.

The QA engineers who win

They build eval harnesses, not just test suites. They curate golden datasets like an asset. They grade behaviour and decisions, not just strings. And they measure their work in regressions caught before release, which is the only metric that survives the move to probabilistic systems.

Questions about this piece

Follow-ups readers ask most often about the argument above.

  • Traditional tests assert an exact output for an exact input. Agentic systems are probabilistic; the same prompt can yield different valid responses. So QA shifts from deterministic assertions to evals: golden datasets, rubric scoring, and LLM-as-judge suites that grade whether behaviour stays inside an acceptable boundary. This is the Eval phase of Pooya Golchian's AIDLC method.

  • More important, not less. The QA engineer designs the eval harness that gates every change, decides which behaviours must be guarded, and curates the golden datasets that catch regressions. In AIDLC, evals are the safety net that lets agent speed translate into shipped systems instead of faster bugs.

  • A unit test asserts an exact value; an eval grades a probabilistic output against a rubric or a golden reference, often using LLM-as-judge scoring. Evals also test the agent's decisions, not just its output, did it call the right tool, in the right order, and stop when it had enough information. That is what matters in agentic systems.

  • On every change, the way unit tests used to, gating each diff the agent generates. In Pooya Golchian's AIDLC method evals are not an end-of-cycle step; they run in CI so a behavioural regression gets caught before it reaches a user, and the QA engineer owns that gate.