Record-and-playback testing is dead — and the recording was always the problem
Record-and-playback testing feels like automation until the first redesign, when the recording breaks or, worse, silently passes. Here's why the recorded artifact was the liability all along — and what to keep instead of a suite of brittle click-paths.
Record-and-playback testing is dead — and the recording was always the problem
Record-and-playback is the most seductive idea in testing, and it has been for twenty years: click through your app once, let a tool capture what you did, and get an automated test for free. No code, no framework, no waiting. The demo always lands, because in the demo the app never changes. Then you ship a redesign, half your recordings go red, the other half go green while testing nothing, and you spend Thursday afternoon re-recording flows you already recorded in June. That afternoon is the actual product. The recording was never the asset — it was the bill, deferred.
I want to be precise about what I'm arguing, because "record-and-playback is dead" is the kind of headline that gets written every year by someone selling the replacement. I'm not saying capturing a click-path is useless — it's a genuinely fast way to pin down one specific, deterministic sequence, and there are narrow places it earns its keep. I'm saying the recorded artifact itself is the liability, that every feature bolted onto record-and-playback over two decades has been an attempt to manage that liability rather than remove it, and that once you can remove it, keeping it is a choice you have to justify. Most teams can't.
What you actually record
When a record-and-playback tool watches you click a button, it doesn't record "the user proceeded to checkout." It can't — it doesn't know that's what happened. It records that an element matching some selector was clicked, then that an input matching some other selector received text, then a wait, then another click. The recording is a list of coordinates in the DOM as it existed at the instant you recorded it. It is a photograph of your markup, and you are about to keep shipping changes to the thing in the photograph.
This is why the failures are so predictable. Rename a CSS class, wrap a field in a new div, swap a <button> for an <a role="button">, reorder two steps in a wizard — none of that changes what the flow means, and all of it can break the recording, because the recording was never about meaning. It was about the specific shape of the page. The tool did exactly what you asked. You asked for a photograph, the room got rearranged, and now the photograph is wrong.
The canonical record-and-playback tool basically admits this in its own feature list. Selenium IDE — still, per its own site, "open source record and playback test automation for the web" — advertises "Resilient Tests" like this: "Selenium IDE records multiple locators for each element it interacts with. If one locator fails during playback, the others will be tried until one is successful." Read that again. The headline resilience feature is recording several selectors per element because the tool already knows one of them will break. That's not a knock on Selenium IDE, which is an honest piece of software. It's the whole category confessing: the recorded locator is so fragile that the state of the art is to record four of them and hope one survives.
Two failure modes, and the second one is worse
Everyone talks about the red failures — the recording that can't find its button and errors out. Annoying, visible, and honestly the good case, because at least it's shouting. You retire an hour re-recording, you grumble, you move on.
The failure mode that should actually scare you is the green one. A recording that still "passes" while verifying nothing. You recorded a checkout flow six months ago; since then the confirmation step moved behind a new modal, but your recording's final assertion was "an element with this class is visible," and that class still exists somewhere else on the page. Green check. The flow is broken in production and your suite is reassuring you. Record-and-playback assertions tend to be the weakest kind — is this element present, does this text appear — because those are the only things the recorder can capture automatically. It records the presence of DOM, not the truth of the outcome, and the gap between those two is exactly where the expensive bugs live. I've written before about why an agent that reads the page finds bugs a fixed script walks straight past; the recorded-script version of that blindness is the same problem with a worse ergonomics story, because at least a hand-written script had a human decide what to assert.
Self-healing is a patch on a wound the recording opened
The industry's answer to brittle recordings is self-healing: when a recorded locator misses, the tool guesses which element you probably meant and rewrites the step. It's real engineering and it genuinely reduces red failures. But look at what it is. It's a system that repairs an artifact that keeps breaking, and it can only ever patch the class of change it recognizes — a renamed selector, a moved node. It cannot heal a redesign, because a redesign isn't a broken locator, it's a different page, and "which element did you mean" has no answer when the element and the flow around it both changed. I spent a whole post on what self-healing actually fixes and what it quietly doesn't; the short version is that healing patches renames, not rethinks, and every healing feature is downstream of the original sin — you stored a photograph, so now you need a machine that keeps re-touching-up the photograph.
Here's the tell. Nobody would design self-healing from scratch as a goal. It exists only to service a decision made earlier: to keep a brittle recorded artifact. Remove the artifact and the entire maintenance apparatus — the multi-locator fallback, the healing pass, the Thursday re-recording — has nothing left to do, because there's nothing pinned to today's DOM to break.
The fork: syntax you replay vs intent you interpret
The reason this is worth arguing now, rather than being a tired complaint about a tired tool, is that the alternative finally exists in a form that isn't "hire an SDET to hand-write Playwright." There are two honest ways to turn a human intention into an automated test, and record-and-playback is one end of a spectrum I've mapped in detail in what "natural language test automation" actually compiles to.
One end: your intention becomes a stored, concrete program — a recording, a script, a compiled command sequence. It replays identically every time, which is a real virtue for the handful of checks that must be byte-exact, and a real liability everywhere else, because the program references the page and the page moves. This is the honest home of record-and-playback and of hand-written scripts alike; the trade-off between owning that program and living without it is a genuine engineering decision, not a marketing one.
The other end: your intention stays intention. You save "sign up with a weak password and confirm the errors are sane," and each run an agent reads the rendered page, decides what to do, does it, and looks at the result before deciding again. There's no recorded locator because nothing was recorded. Rename the button, restructure the form, ship the redesign — the instruction was never about the button, it was about signing up, so there's nothing to break and nothing to heal. You give up byte-identical replay; you buy immunity to the exact change that kills recordings. For most flows, most of the time, that's the trade you actually want — and it's the case I've made against reflexively owning your own script suite from the other direction.
Where a recording still earns its place
I said I'd be precise, so here's the honest boundary. If you have a single, deterministic, high-stakes click-path that must be verified the exact same way forever — a regulated approval step, a specific keyboard sequence, a pixel-precise interaction — a recorded or scripted artifact is a legitimate tool, and its determinism is a feature. Pin those. The mistake isn't using a recording for the two or three flows that need one. The mistake is using recordings as your default — building a suite of hundreds of photographs of a UI you're actively redesigning, and calling the maintenance that generates "test automation." That's not automating your testing. It's automating the creation of homework.
Try the version with nothing to re-record
The fastest way to feel the difference is to describe a flow instead of recording it, then change your app and run it again without touching the test. Point a Test Scenario at your staging URL and paste this:
Nothing in that instruction names a button, a class, or a step order — so when you move the confirmation behind a modal next month, there's no recording to re-record and no locator to heal, because none was ever stored. Each run leaves a full Monito Session — screenshots, network log, console, and the agent's reasoning — and the whole run comes out as JSON if you want to gate a deploy on it. Your first run is free; it's $99/mo after that (Enterprise $129/mo), roughly 8–13 credits (about $0.08–$0.13) per run. Record a flow in your old tool, then describe the same flow here, then redesign the page — and see which one you have to touch afterward. That's the entire argument, and your Thursday afternoons are the stakes.