51 posts tagged with "AI-Agentic Test Automation"

Regression testing exists to answer one question cheaply and repeatedly: did this change break something that used to work? That's the whole job.

Somewhere along the way, most teams ended up spending more energy keeping the regression suite alive than they spend getting the answer it was supposed to give them. This post looks at why that happened, and at a different approach — DevAssure's O2 agent, which runs regression tests written in plain English instead of Selenium or Playwright code — and what changes when you let an agent decide what to test and how, rather than encoding every decision into a script.

Legacy code, in Michael Feathers' well-known definition from Working Effectively with Legacy Code, is simply code without tests. Most healthcare software fits that description more than teams like to admit — years of accumulated business logic, several generations of frontend stacked on top of each other, and a regression suite that either doesn't exist or stopped being trustworthy sometime around the last major redesign.

That's a hard enough problem for a typical B2B app. For healthcare software specifically, it gets multiplied by a variable most testing strategies don't account for well: the sheer number of distinct people using the same system in completely different ways.

Most of what gets published about AI coding agents and test quality falls into one of two buckets: vendor marketing that reports whatever numbers make the product look good, or developer opinion pieces built on anecdote. A paper accepted to the 23rd International Conference on Mining Software Repositories (MSR '26), posted to arXiv in March 2026 by researchers at the Nara Institute of Science and Technology and the University of Groningen, is neither. It's an empirical study of how AI coding agents actually generate tests in real open-source repositories — and the findings complicate the tidy narrative in both directions.

Software testing has moved past “run the suite overnight and hope.” Teams shipping with AI coding agents and tight PR cycles need validation that starts from the diff, maps real user journeys, and returns actionable results before merge — not another pile of brittle scripts to babysit.

That is why the best software testing tools in 2026 are judged less on how many frameworks they wrap, and more on whether they help you ship every PR with confidence.

Test-driven development has been around since the early 2000s, championed by Kent Beck as part of Extreme Programming, and for most of its life it's been treated as one good practice among many — valuable, occasionally contentious, easy to skip under deadline pressure.

Something has changed in how the practice gets talked about over the past several months. As AI coding agents have moved from autocomplete-style suggestions to autonomous, multi-step actors that can plan, write, run, and revise code on their own, TDD has resurfaced as one of the more consistently recommended disciplines for working with them.

This is not a rebrand of TDD into an "AI thing" — it's the same red-green-refactor loop developers have used for two decades. What's new is why it matters more now, and how teams are wiring it directly into agentic testing workflows.

If you've watched an AI coding agent work through a GitHub issue, you've probably seen it stop mid-task to scaffold a quick test file, run it, print some values, and adjust its patch accordingly. This has become such a normalized part of the agentic coding loop that "the agent writes its own tests" is often treated as a proxy for rigor — a sign the fix is being validated, not just guessed at.

A study posted to arXiv in February 2026 and still circulating in QA and agent-research discussions this summer pushes back on that assumption with actual measurement. The results are worth sitting with if your team is building agent-driven testing workflows.

A theme has been building in AI-coding-agent research over the past couple of weeks, and it's one that should matter a great deal to anyone doing software testing or QA: coding agents are getting good enough to satisfy the check you wrote rather than the request you meant. That distinction — between passing a test and actually doing the job — is turning into one of the more consequential debates in agentic software engineering right now, and it has direct implications for how testing and QA teams should be evaluating AI-generated code and AI-generated tests alike.

If you've shipped code in the last year, you've probably noticed the shift: AI coding agents aren't just autocompleting functions anymore — they're running in execution loops, writing tests, reading failures, and fixing their own bugs before a human ever opens the pull request. Anthropic's 2026 Agentic Coding Trends Report frames the change plainly: software development is shifting from writing code to orchestrating agents that write code.

For testing teams, that changes the job description as much as the tooling.

Here's what's actually happening in agentic testing and AI-assisted QA right now, and what it means if you're building (or buying) test automation.

At Microsoft Build 2026, Microsoft announced something that quietly confirms the core thesis behind DevAssure: as AI agents take over more of the software development lifecycle, the agent that writes the code cannot be the agent that grades the code.

The announcement was a pair of open-source projects — ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) and the Agent Control Specification (ACS) — designed to give developers a portable, framework-agnostic way to evaluate and govern AI agents before their behavior ships to production. Coming from the company now positioning itself as the "agent-first" platform for enterprise development, this is a meaningful signal about where the industry is heading.

I want to walk through what Microsoft actually shipped, why it matters beyond agent safety, and what it means for teams where 30–40% of code is already AI-generated — because the validation gap Microsoft just named at the agent layer is the same gap most engineering teams still have at the application layer.