How to Do Regression Testing Without a QA Engineer

TL;DR: Regression testing just means checking that your last change didn’t break something that already worked. You don’t need a QA engineer to do it; you need a short list of critical flows, written in plain English, that you re-run after every change. The trick is making the re-run cheap enough that you actually do it.

Here’s the moment this post is about. Your app works. You send one more prompt to add a feature, the builder generates the change, and somewhere in that change the signup form quietly stops working. You don’t find out for four days, because you were looking at the new feature, not the old one.

That’s a regression, and catching them is the single most valuable thing a QA engineer does. So what do you do when you don’t have one and aren’t going to hire one?

What regression testing actually is

Strip the jargon and it’s one question: does everything that worked before the change still work after it? Not “is the new feature good,” that’s a different check. Regression testing is re-walking the paths you’ve already shipped, every time anything changes, because changes have side effects the person (or AI) making them didn’t intend.

The reason it needs a process rather than vibes is that the failure mode is silent. A broken new feature announces itself; you’re staring right at it. A broken old feature just sits there, failing for users, while your attention is somewhere else.

Why the standard advice doesn’t fit you

Search this topic and the advice you’ll find is written for a different reader. One guide from Rainforest QA lays out the four standard options for teams with no QA function: have your developers write tests in a framework like Playwright, hire a QA engineer, buy a no-code testing tool, or outsource the whole thing. Their own survey of 625 developers found that 55% of teams using open-source test frameworks spend 20 or more hours a week just maintaining the tests. Twenty hours. Per week. On upkeep.

Notice what every one of those four options assumes: you have developers, or the budget to hire one. The newer AI testing platforms make the same assumption one layer down; they connect to your GitHub repo, read your codebase, and run in your CI pipeline on every pull request. That’s a fine model if you have a repo, a pipeline, and pull requests.

You have a Lovable project and a live URL. Your “deploys” are prompts. There’s no PR to hook into, and the maintenance burden those 20 hours a week go toward is maintenance of test code you were never going to write in the first place. We went deeper on this mismatch in QA testing for AI-built apps; the short version is that the entire tooling ecosystem assumes scaffolding you don’t have.

The process: a flow list, not a test suite

Here’s what actually works at your scale, and it starts with a piece of paper, not a tool.

Write down the three to five flows that would genuinely hurt if they broke. For most apps that’s some version of: a new user can sign up, a returning user can log in, and the core action completes, whether that’s booking a slot, submitting a form, or checking out. Rank them by damage, not by how easy they are to check. Lovable’s own testing docs push in the same direction: verify user workflows, in small increments, as you build.

Now write each flow as one or two sentences, the way you’d explain it to a friend covering for you. “Sign up with a fresh email, land on the dashboard, see the empty state.” That sentence is your regression test. Not a script, not a framework. A sentence.

The rule that makes this regression testing rather than a one-off check: re-run the whole list after every change that touches the app. Every prompt you send is a change. The AI builder rewrote real code to fulfill it, and it had no idea which of your existing flows it was allowed to break.

Manually, this takes maybe fifteen minutes a round. That’s genuinely fine for week one. It stops being fine around the third week, when you’re shipping several prompts a day and the fifteen-minute walk-through is the step you start skipping. Every skipped round is a bet that this particular change was side-effect free, and you’re betting blind.

Making the re-run cheap enough to actually happen

This is the part WayRunner was built for. The sentences you just wrote are the input. You paste your app’s URL, save each flow as a plain-English instruction, and a real Chromium browser runs it exactly like a user would, screenshotting every step so a failure shows you the exact moment things went sideways.

One design decision matters specifically for regression use: every WayRunner run is hard-capped at 40 steps and 10 minutes. That cap exists because a regression run you repeat after every change has to fail loudly and fast when something’s wrong; a test that hangs, retries forever, or silently burns through your usage is worse than no test, because you stop trusting the green checkmarks. A capped run either finishes or fails with a screenshot pointing at the step that broke.

Flows behind a login work too; credentials go in an encrypted vault and are injected into the browser at the moment they’re needed, so the AI planning the steps never sees your password. The full setup walkthrough is in how to test your Lovable, Bolt, or Replit app before you ship it.

The loop ends up looking like this: prompt a change, re-run your saved flows, read any failure, fix or roll back. Minutes, not a hired role.

The takeaway

You don’t need a QA engineer to do regression testing. You need their habit: a ranked list of flows that must not break, checked after every single change, with a cost per check low enough that you never skip it. Write the list today, even if you run it by hand for now. The list is the hard part; the automation is just what keeps you honest in week three.

When you’re ready to stop clicking through it yourself: wayrunner.run/#signup.