Testers describe a manual regression pass as boring, and the complaint points at the wrong cost. Repeating a check somebody has run nine times before is cheap. The expensive part starts when one of those checks fails: the walk back to the tracker, the report rebuilt from memory, and the ones that come back irreproducible.
The repetition is the cheap half of a regression pass
Watch the clock on two passes over the same regression checklist. The pass that finds nothing finishes roughly when somebody predicted it would. The pass that finds six things does not, and those six checks were no slower to run than the ones that passed. Everything that overran happened after the failure, in a different window, in a form.
That is the shape the tedium argument misses. Boredom scales with the length of the checklist, which a team already knows and plans around. Effort scales with the number of findings, which nobody plans around, because the pass is budgeted as though its output were a tick in a column. A build that breaks in several places costs a tester time no estimate contained.
Most of the advice written for this problem is about the checklist: prune it, risk-weight it, run the highest-value cases first. Our own QA checklist asks the regression group for something stricter and different, that the suite ran against this build and that each of its failures was triaged as a real defect or a test defect. Neither kind of advice touches the part that overran.
Automation took the checks and the evidence with them
The standard answer to all of this is to automate the pass, and half of that answer is right. A check that runs every release, must never be skipped, and can be expressed as a script belongs in the pipeline rather than in somebody’s afternoon.
What survives that programme is a residue, and the residue is defined by resisting the exact property automation needs. Rendering that looks wrong rather than being wrong, a flow through a third-party checkout nobody can drive, a journey costing more to script than to walk, and the exploratory circling around the scripted path where a tester notices the thing no case was written for. A team can automate for years and still hold a pass shaped like that.
Now compare what each half produces at the moment it finds something. A failing automated case writes its own report: the assertion, the artifacts the runner captured, the build it ran against, and the environment it ran in, all attached without anybody being asked for them. A person spotting the same defect on the same page produces a memory and a sentence.
The instrumentation went where the checks went, and the pass that resisted scripting was left holding the weakest evidence in the release process.
A finding written from memory gets filed twice
A regression finding is harder to write than a fresh bug report, and the reason is specific: the tester knows the behaviour used to work, and does not know when it stopped. The one piece of information that would narrow the search is the piece memory does not hold.
Around that sits the round trip, and each of its steps takes something away from the pass that made it.
| Step in the round trip | What the pass loses to it |
|---|---|
| Leaving the page for the tracker | The state that produced the defect, which the next navigation overwrites |
| Re-describing what just happened | The detail nobody wrote down while they were still looking at it |
| Reconstructing build, browser and viewport | Accuracy, because those get answered from habit rather than from the tab |
| Attaching a screenshot taken afterwards | The seconds before it, which is where the cause is |
| Returning to the checklist | The place in it, and the hunch about what had already looked odd |
Every entry in the right-hand column is evidence that existed on the page and does not exist in the ticket, and the last one is what turns a single pass into several. Steps to reproduce written under those conditions are a reconstruction rather than a record.
Then the ticket comes back. A finding written from memory closes as irreproducible, which is the failure UAT best practices end where the finding starts follows from the engineer’s side. What a regression pass adds is the second turn: the check fails again next release, gets written up from memory again, and the second report is no better sourced than the first, because nothing about the pass changed.
A pass that files in place stays one pass
The alternative is to file without leaving the page under test. A review session puts the tester on the site they are testing, with a picker: point at the element that is wrong, and the ticket is written against that element.
What makes that work over a long pass is what happens after the send, which is where a filing gesture usually costs a sweep its momentum.
| What a sweep needs from a filing gesture | What the session does |
|---|---|
| The finding named against the thing itself | Stores the picked element as a sanitized DOM selection: the selector, the strategy that produced it and a confidence in it, the tag, its role and accessible name, and the rectangle it filled in a stated viewport |
| Confirmation, without a decision to make | Shows the ticket’s stage, type, priority and id, then takes itself down after four seconds |
| Nothing to dismiss | Puts no target on the card at all, because it floats over a picker that is already armed for the next element |
| A page left clean | Removes the card, the ring and the pin together, so a long pass does not cover the page in marks that describe finished work |
| The next finding, straight away | Re-arms the picker behind the card |
| A ticket in the normal pipeline | Files into Received, on the same board and with the same evidence as every other report |
The middle rows are the ones a pass feels. A confirmation somebody has to close is a decision, and a decision taken at the rate a regression pass files at becomes a chore of its own, so the card reads itself out and goes. The card takes no pointer events at all, so the countdown runs out wherever the reviewer’s pointer happens to be: a hover that held it open would hold it open forever, because a pointer mid-pass crosses the page constantly, hunting for the next element.
Six findings on one screen then cost one sweep rather than six departures, and the checklist never loses its place. The review mode page carries the rest of the mechanics, including who is allowed to open a session.
The pass that survives automation is the one nobody instruments
The tooling followed the work that was easy to describe. Test runners, reporters, artifacts on failure, retries with traces attached: all of it grew around the checks that could be written as scripts. The pass left over, the one that exists precisely because its checks resisted being written down, was handed a spreadsheet and a browser tab pointed at a tracker.
That is the gap worth closing before the next argument about which cases to automate. A manual pass whose findings arrive carrying the state they were found in stops producing the second filing, and the second filing is where the hours went.
Three of the constraints above are ours to impose, and a release calendar has to absorb them. Review sessions are a Pro capability, and each one stays valid for eight hours, so a pass spread across a two-day release window is opened again on the second morning. Letting somebody outside the team open a session is off until a project turns it on, and it then only works from a domain that project has registered. A regression backlog that lives in Jira keeps living there; what arrives from a pass is a ticket carrying the evidence it was found with, not a replacement for the system of record.
