Why I Built Ramen (and Why QA Needed a QDE)
A month ago I wrote a post that had been sitting in my head for a while, mostly unformed, until I finally forced myself to write it down. The question behind it was simple: why do developers get entire environments built around how they work, while QA engineers are still expected to stitch a pile of unrelated tools together and hold the whole thing in their head?
That post turned into an idea. This week, the idea turned into something people can actually install and use. Ramen 0.1.0-preview.1 is out. Before I talk about what it is, I want to talk about why it exists, because the why is the part I actually care about.
The problem I kept running into
I work across QA automation and full-stack development, so I get to see both sides of this pretty regularly. On the development side, tooling is a solved problem. Open an IDE, and it already understands your project, your Git history, your terminal, your build process, your dependencies. Everything is built around one thing: the software you're building.
QA doesn't get that. A QA engineer's day might start with a requirement, move into reading a product guide, jump into inspecting the frontend, then into writing automation, then into a terminal to run a Docker container, then into a browser to check a locator, then back into an IDE to fix the test that just failed for reasons that have nothing to do with the actual bug. None of these tools know about each other. The browser doesn't know what branch you're on. The terminal doesn't know what element you just inspected. Docker doesn't know what suite is about to run against it.
That's not really a tooling gap in the sense of "we're missing a tool." It's a gap in shared state. Every tool a QA engineer touches in a day knows something useful, and none of that knowledge is visible to the others. You end up being the integration layer, manually, every single time.
Why I didn't just build another test tool
There's no shortage of test automation tools, AI test generators, or wrappers around Playwright and Selenium. I wasn't interested in adding one more to the pile, and I don't think that's actually what was missing.
What kept nagging at me was a much more basic question: if you designed a development environment around Quality Engineering from the ground up, instead of adapting a developer IDE to fit QA after the fact, what would it actually look like?
The answer I kept arriving at was that the system under test needs to be the centre of the project, not the source code. A QA workspace isn't just a folder of test scripts. It's the requirements, the product knowledge, what you know about the frontend, the environments you test against, and the tests themselves, all living in the same place, understanding they belong to the same context.
That context turns out to matter a lot once AI gets involved. Telling a model to "generate a Playwright test for this feature" without giving it any of that surrounding knowledge is asking it to guess at conventions it has no way of knowing. Give it the workspace instead of just a prompt, and the generated test actually looks like something your team would have written.
I called this idea a QDE, a Quality Engineering Development Environment, on purpose, because I think QA deserves the same category of tool developers have had for years. Not a QA IDE with a few extra buttons. An environment built around the actual job.
Who this is actually for
I built Ramen with a fairly specific person in mind, because I've spent a lot of time being that person. Someone doing QA automation who is tired of context-switching between five disconnected tools to do one task. Someone who wants the browser they're testing in to actually be part of their workflow instead of a separate window they alt-tab to. Someone who's excited about AI-assisted testing but has felt the ceiling of what a bare prompt can actually produce without real context behind it.
It's not aimed at replacing anyone's stack. If you use Playwright, keep using Playwright. If you use Git, Docker, or Claude Code, keep using all of them. Ramen isn't trying to be the twentieth tool in the pile. It's trying to be the thing that finally understands how the other nineteen relate to each other.
What the last month actually looked like
Writing the idea down was the easy part. Turning it into something real was a different exercise entirely, and I want to be honest that it didn't come out fully formed. A month ago this was a concept and a handful of half-working experiments. Since then it's become an actual application, with workspaces, system-under-test context, browser execution built into the environment, an integrated terminal, run configurations, and real testing workflows sitting on top of all of it.
There were a lot of decisions along the way that I'm still not sure I got right. How much structure to impose on a workspace versus how much to leave open. How tightly to couple the browser and the inspector to locator generation. How much of the AI integration should assume a specific framework versus staying framework-agnostic. Some of those answers are probably going to change as more people actually use this and tell me where it breaks.
Why release it now, in this state
I could have kept building quietly for another few months before showing anyone. I decided against that on purpose. I don't want to present Ramen as a finished answer to a problem I only fully articulated a month ago. I'd rather put out something real, rough edges included, and find out from actual usage whether the core idea holds up.
Maybe it doesn't. Maybe the existing pile of disconnected tools really is the right approach and I'm solving a problem that isn't as painful for other people as it is for me. But I don't think anyone has seriously tried building an environment around the Quality Engineer instead of retrofitting one meant for developers, and I'd rather find out by shipping something than by thinking about it for another six months.
Ramen 0.1.0-preview.1 is out today. If you do QA automation and any part of this has annoyed you as much as it's annoyed me, I'd genuinely like to know what you think.
Top comments (0)