Blog
Key takeaways:
Every vendor page on this topic answers the same question, which is which tool to buy. The more useful question is which tests belong in a low-code tool at all, because getting that sort wrong is what produces a suite nobody trusts and nobody will maintain.
At VAULT we inherit other teams' test suites regularly, and the pattern is consistent. The recorded tests that cover a login and a checkout are still running two years later. The ones that cover anything timing-dependent were switched off in month three and nobody mentioned it.
This guide is about the testing side only. Choosing a platform to build applications on is a different decision with a different shortlist, because the best low-code platforms are built to produce software rather than to exercise it. The tools below do nothing but test.
A low-code test tool records what you click, or takes a plain-English description of a flow, and turns it into a repeatable test. It then manages the parts people find tedious: finding elements on the page, waiting for them to appear, running the test across browsers, and reporting what failed.
The "low code" part matters. Most of these tools are not no-code at all, and the ones that scale always have a code escape hatch for the cases the recorder cannot express. Vendors differ on how honest they are about this.
What the tool does not do is decide what to test. A recorder captures steps; it does not pick which inputs matter, which boundaries to probe, or which combinations are worth covering. That is test design, and it is a separate discipline with its own international standard. ISO/IEC/IEEE 29119-4, published in 2021, exists specifically to define the techniques used to design test cases.
One layer is recorded and replayed; the other is decided and never automated.
Keeping those two jobs apart is the whole of this article. A low-code tool is an execution and maintenance layer sitting under decisions a person still has to make. Most application development tools split the same way, which is why a team that cannot say who owns the decisions is not rescued by buying another one.
Low-code test automation earns its place in a narrow band, and the band is defined by who owns the knowledge rather than by technical difficulty.
The ideal case is a flow that is business-critical, changes rarely, and is best understood by somebody who is never going to maintain a test framework. A support lead who knows exactly which five checkout paths generate complaints can record those five paths in an afternoon. Asking that person to learn a test runner, a package manager and a CI pipeline first means the tests never get written.
That is the real argument for these tools, and it is about organizational shape rather than speed. Three conditions make a flow a good candidate:
Checking that the flows you picked are still the ones that matter is worth an hour, since a changed user flow can leave a carefully recorded suite testing a path almost nobody takes any more.
All three have to hold together, and the last one is not a technical test.
When all three conditions hold, a recorded test is the right call and the maintenance burden stays small. When the first one fails, everything below happens instead.
Competing guides tend to compress this into a four-bullet "limitations" list. The specifics matter more than the category, because each failure mode has a different workaround.
A recorded test remembers how to find each element. When the UI changes, that memory goes stale, and the test fails for a reason that has nothing to do with a bug.
Most vendors answer this with self-healing, which is marketed as the tool repairing itself. In practice it means the tool makes a guess about what the broken step was trying to do. Engineers in a Reddit thread on no-code test tools put it bluntly, saying some self-healing just means the tool will guess at what a broken test should be doing, and that recordings stay brittle when an element moves or a section is inserted.
The risk is not the guess, it is the direction of the guess. A healed test that passes tells you nothing, and a tool can always make a test green by quietly weakening what it asserts. A failing test is information; a test that was silently repaired into checking less is a false sense of coverage.
So treat every auto-repair as a change requiring review. If your tool cannot show you a diff of what it changed, that is a reason to look elsewhere.
Login is the first flow everyone automates and the one most likely to stall. Password login records fine. Anything with a second factor needs deliberate setup.
Some tools handle time-based one-time codes directly. mabl's own documentation describes storing the authenticator secret as a credential and generating the code during the run, and notes the practical constraint plainly: the code refreshes every 30 seconds and is invalid after that, so the test has to submit it immediately.
Email or SMS codes are harder, because the test now depends on a mailbox. The cleaner answer is usually a test-only path: a seeded session, or a bypass that exists in staging and nowhere else. That is a change to the application, which means it is an engineering decision rather than a tooling one.
Component libraries that use shadow DOM can be invisible to a recorder, and the distinction that decides it is whether the shadow root is open or closed. mabl's docs are explicit that only open shadow DOM is supported, that closed shadow DOM is not, and that elements inside a shadow tree cannot be targeted with XPath at all.
Third-party frames are the related problem. A payment widget or an embedded chat tool lives in someone else's iframe, loads on their schedule, and changes without telling you. Automating through one couples your test suite to a vendor's release cycle.
The usual answer is to stop testing through the third party and mock it instead, verifying that your side sends the right request and handles the responses. You give up end-to-end fidelity on that step and get a test that passes for the right reasons.
Uploads work for ordinary file inputs and get awkward quickly. In mabl's documentation, a file supplied as a data-driven variable stays with the test that uses it, and only downloaded files travel between tests, and then both tests have to sit in the same plan with the downloading test running first. Every tool draws that line somewhere different, so check yours rather than assuming.
The bigger constraint is data rather than files. A test needs a known starting state, and manufacturing that state repeatedly is the part no recorder helps with.
This is where the industry's own numbers are striking. The World Quality Report for 2025 to 2026 puts it in one sentence on its findings page: 60 percent of organizations struggle with secure, scalable test data, while 58 percent cite challenges in adopting AI-powered tools. Authoring was not the bottleneck anyone named.
Anything that depends on timing, ordering or a live connection resists recorded testing, because the thing you need to assert is a sequence rather than a state. We built Wayward as a real-time adventure tracking app, and that class of feature is exactly where a click-and-replay test has nothing useful to check: the screen looks the same whether the position stream is arriving in order or not.
Nondeterminism also produces the most expensive failure in testing, which is the flaky test. Google's testing team published figures from its own enormous suite in 2016: about 1.5 percent of all test runs reported a flaky result, almost 16 percent of its tests showed some level of flakiness, and about 84 percent of observed pass-to-fail transitions involved a flaky test rather than a real regression.
The last of those three is the one to remember, with the caveat that it describes Google's suite and not yours. Once a large enough share of red builds turns out to be noise, people stop reading them, and a suite nobody reads is worse than no suite because it costs money and provides false reassurance. No amount of self-healing addresses this, since the cause is concurrency and third-party behavior rather than a stale selector.
Here is the decision table. One column needs labeling honestly: the approach column is our judgment from inheriting suites, not a vendor claim or a standard, while the why column cites the source behind each criterion. Vendor-specific rows are marked as such and should be checked against whatever tool you actually use.
| Test | Approach | Why |
|---|---|---|
| Stable repeated UI flows (login, checkout, key forms) | Low-code | The owner of the knowledge is often not the owner of a framework |
| Logic-heavy or data-driven checks | Code, or low-code with a reviewed code step | Computed expectations outgrow a recorder quickly |
| Login with a time-based one-time code | Low-code, with the secret stored as a credential | mabl's docs: the code is invalid after 30 seconds |
| Login with emailed or texted codes | Code, with a staging-only bypass | The test otherwise depends on a mailbox |
| Components in closed shadow DOM | Not automatable through the UI layer | mabl's docs: closed shadow DOM is unsupported |
| Third-party iframes and payment widgets | Mock the dependency | Third-party code is a named flakiness cause |
| Real-time, streaming or ordering-dependent behavior | Code, asserting on sequence | The assertion is a sequence, not a screen state |
| Anything you will run once | Do not automate | A recorded one-off is pure maintenance debt |
| Creating the test data itself | Neither tool type solves this | 60 percent of organizations report struggling with it |
Work down the list with your own backlog beside it and the suite designs itself. In the suites we have built and inherited, roughly a third of what a team intended to record turns out to belong in code, and one or two items should not have been automated at all.
Authoring a test takes an hour. Keeping it alive takes years, and almost nothing written about low code test automation tools addresses the second number.
Decide the owner before buying, because the answer determines whether the tool fits. If a manual tester records the tests and an engineer owns the framework underneath, that works and it is the arrangement most vendors quietly assume. Where nobody owns the framework, what we usually find is a suite that has decayed into a set of skipped tests inside about two release cycles.
The second number is the one that decides whether the tool fits.
Reddit practitioners describe the failure mode precisely. In a discussion of whether no-code tools are good enough now, the most upvoted reply says they feel great at first and the limits appear as case counts grow, so teams end up back in code. Another contributor describes testers copying and pasting recorded steps without understanding them, which is anecdotal and recognizable.
The structural fix is the same one that works for any shared asset: someone reviews changes. A recorded test that gets edited by whoever noticed it failing is not a test, it is a changelog of other people's guesses.
Suite ownership is a staffing question as much as a tooling one, and the honest version of building a technical team includes asking who gets paged when the Friday-night suite goes red.
Pricing in this category is unusually opaque, and that is worth knowing before you build a shortlist, because half an evaluation can go by before you learn a tool needs a sales call. Each figure here comes straight off the vendor's published tiers, checked on 2026-10-05.
| Tool | Published price | Basis |
|---|---|---|
| Katalon | Yes, list $2,199 per seat per year, discounted to $1,000 for a first purchase when checked, plus a free tier | Annual, per seat |
| BugBug | Yes, free tier, then Core $99, Pro $189, Business $559 per month | Monthly rates billed annually |
| mabl | No, credit-based consumption | Quote |
| Virtuoso | No | Quote |
| Testsigma | No | Quote |
| ACCELQ | No | Quote |
| Ranorex | No | Annual or multi-year license |
| Leapwork | No | Quote |
| Tricentis Tosca | No | Quote |
| Playwright codegen | Free and open source | None |
| Selenium IDE | Free and open source | None |
Two of the nine commercial tools in that table publish a price, and seven require a conversation. That is normal for enterprise test tooling rather than a criticism, and it has one practical consequence: budget for a procurement cycle, not a credit card.
Sorted by whether a price exists at all, the shortlist looks different.
The two free rows change the argument more than anything else in the table. Playwright's code generator records a browser session and writes test code, choosing role, text and test-id locators as it goes.
That removes most of the "you need to be able to code" barrier these platforms were sold on. If your team already owns a repository and a CI pipeline, start there and buy a tool only when you can name what it adds.
Teams without that harness often have us build it, which is ordinary development work rather than a tooling purchase, and it leaves them owning the result.
One question separates a tool you can leave from a tool you cannot: can you get your tests out as a readable file?
Ask it in the first demo, because the answer predicts the next three years. Tests held only in a vendor's database are not an asset you own, and the cost of switching is the cost of rewriting every test from scratch.
BugBug, for instance, imports and exports tests as human-readable YAML from the app, a CLI and its API, on every plan including the free one. That is the behavior to look for regardless of which vendor you end up with.
Exportability also decides whether tests can live in version control alongside the code they test. Without that, you cannot branch tests with features, review them in a pull request, or find out which change broke them, and those three things are most of what makes a suite trustworthy.
The same discipline applies when the UI changes under a suite you inherited, which is the moment most recorded tests die. A test suite is never finished for the same reason the product is not: it ages at exactly the rate the thing it covers changes.
Use a low-code tool for the repeatable middle, write code for the edges, and automate nothing you will run once. That sort is worth more than any tool comparison, because it is the thing that determines whether the suite survives contact with a redesign.
Deciding the owner comes next, and that decision belongs in writing. A tool choice made without naming the maintainer is a decision to find out the hard way in about six months.
If you have inherited a suite you do not trust, it is usually faster to sort it than to replace it. Contact us if a read-through would help; the fastest win is usually deleting the tests that have stopped earning their runtime.
No-code tools offer no escape hatch: whatever the recorder cannot express, you cannot test. Among low code no code test automation tools, the ones that scale let someone drop into script for the cases the recorder cannot handle, which covers most computed or data-driven checks.
The practical consequence is that a low-code tool needs at least one person who can write and review that code. A low code no code automation testing tool sold purely on needing no engineers is describing its ceiling rather than its strength.
No, and the reason is about design rather than capability. Automation re-runs checks somebody already decided were worth running, which makes it good at regression and useless at discovering what you did not think of.
Exploratory testing, usability judgment and anything requiring a human to notice something is off remain manual. The split that works is automating the repeated checks so testers spend their time on the parts a script cannot do.
Treat it as a guess that needs review, not a repair. Self-healing re-identifies an element the tool can no longer find, and a tool can always make a test pass by asserting less than it did before.
Require a tool that shows what it changed, and review healed tests the way you would review a code change. A silently repaired test is the main way false confidence enters a suite.
Mostly for reasons that have nothing to do with the recorder. Google's testing team named concurrency, non-deterministic behavior, third-party code and infrastructure as the causes, and reported in 2016 that about 84 percent of pass-to-fail transitions in its own suite involved a flaky test rather than a real failure.
The fix is to stop automating the nondeterministic flows through the UI and mock the dependencies instead. Re-running until green hides the problem and trains people to ignore red builds.
Anything you will run once, anything where the pass condition is a human judgment, and anything built on a third party you do not control. Each of those costs more in maintenance than it returns in confidence.
Rarely-run flows are the most common mistake, because automating them feels thorough. A test that runs twice a year still breaks every time the UI changes, and somebody still has to fix it.
Most inherited suites hold a handful of tests doing real work and a long tail nobody trusts any more. Contact us if you want that sorted into keep, rewrite and delete, with an honest estimate of what getting the daily run green again involves.
