Bringing AI into a QA engineer’s day, and making life easier

Roman Pluzhnikov — Tue, 23 Jun 2026 08:58:24 +0000

Developers got Cursor, Copilot, and a dozen other AI tools. QA got a web form in someone else’s TMS. Let’s fix that.

Two pains this whole thing started from
Two things hurt the most when you maintain test documentation.

First: cases sit there like dead weight. You write them once and open them again at release. The spec drifts in the meantime, and by release day half your suite is checking last quarter’s behavior, simply because nobody got around to updating it.

Second: maintaining a large case base eats a ton of time. The fatter the suite, the more manual work (find what a change touched, then rewrite it), and that’s exactly the time you don’t have. Tests pile up, and keeping them current gets more expensive by the week.

That’s where the idea for Kensa came from: a TMS plus IDE built only for QA, with everything that follows from that.

A full TMS, with caveats for now
It’s a TMS, except your cases don’t live in someone else’s cloud. They’re plain .md files under .tms/suites/ in your own git repo. I edit them in a normal editor: title, priority, status, tags, preconditions, steps as "Action plus Expected." Suite tree, search, bulk actions, plans, runs, shared steps, a field-schema designer. It's all there.

Yes, there’s no integration with autotest frameworks yet, and no report ingestion. But both are the number one item on the roadmap and land in the coming weeks.

The agent you already use, now inside your cases
My guess is a lot of you already pay for Claude, Codex, or Kimi, or run something local. Now you can put them to work right inside your test-case base. And if you’re on Claude or Codex, you can install a plugin straight from Kensa that adds a whole lot more, but that’s a story for a later post. A built-in AI assistant of our own is also in the works, sitting at number two on the roadmap.

A CLI so agents handle cases properly
Give an agent nothing but a terminal and it wanders the project blind and writes the wrong thing. So the app ships with kensa-cli, a console tool written in Rust, 30+ commands, already on the terminal’s PATH. Nothing to install.
Now the agent doesn’t guess. It calls kensa filter "tag:smoke", pulls context with kensa context, and checks itself with kensa lint after editing.

Moving in from your old TMS
If your cases already live somewhere, bringing them over is easy. The import wizard handles TestRail CSV, Qase JSON, Allure TestOps, and universal CSV/JSON/YAML/XML, while “Adapt with AI” hands the agent a couple of your real cases so it fits the schema to them itself. Export back out works too, so you can try it without breaking anything on your side.

A belt of everyday tools
While I was at it, I pulled a pile of small tools into Kensa so I’d stop leaving the editor for little things: an HTTP runner (requests as .http files), a Browser that wraps Chrome over CDP for the agent to drive from the terminal, Routines (reusable browser-QA scenarios), plus Regex, JWT, JSON diff, and a timestamp converter.

Blueprints
The most experimental thing, and the one I’m hooked on right now, is Blueprints: node-graph automation where an AI agent is a first-class node. You can send an agent off to do something, then take its output and feed it into the next request. The number of possible flows is huge already, since there are plenty of nodes, and I plan to keep building this out.

Take it for a spin → kensa-ide.com. And I really do want feedback: building in public only works while someone’s there to poke it with a stick and tell you what’s broken.

DEV Community: Roman Pluzhnikov

Bringing AI into a QA engineer’s day, and making life easier