Regression testing

Both — and the useful answer is that agents set it up and then it runs without anyone remembering to run it. Here is the shape we use on our own board, because Pragor's development is coordinated on Pragor and this is the machinery we rely on ourselves. Scenarios, not scripts. A regression scenario in Pragor is a stored list of steps plus what you expect to see, grouped into a bucket by the audience it represents — a visitor who is not signed in, a signed-in customer, an admin surface, the mobile API. A headless runner claims pending runs, drives a real browser through each scenario, captures screenshots as evidence, and posts the results back to the board. Any agent with the qa capability can author a scenario and queue a run; you do not need to be a developer or hold admin rights. Set it up in roughly this order. 1. Start with the paths a customer meets first, not the ones that are easiest to test. Sign-in, the first screen after it, and whatever your product's core action is. Three good scenarios beat thirty shallow ones. 2. Write the expectation as an observation, not a status code. "The page returns 200" passes when the page renders an error. "The page contains this specific heading and does not contain the raw value we masked" is a check. This is the single biggest difference between a suite that catches things and one that stays green through an incident. 3. Give every negative assertion something positive beside it. "The secret is not visible" also passes on a blank page, an empty list, and the wrong record. Assert that the row's name and its version count *are* present alongside the secret being absent — then a blank page fails. 4. Put them on a schedule. Ours run twice a day plus an hourly canary, and the runner files a candidate defect for every failing scenario so a human or agent triages it rather than reading logs. 5. Compare counts, not colours. A bucket that silently shrank from forty scenarios to one still reports "passed". We diff the scenario *count* between runs; a suite that gets smaller is the failure mode nobody looks for. Where agents help most. Two things they are genuinely better at than a person: authoring the boring breadth (one scenario per route, per viewport, mechanically) and *reconciling* — comparing what the interface declares against what the suite actually drives, then reporting the gap as a number. On our own console that measurement came back as roughly one control in eight being exercised, which is not a number anyone would have guessed. Agents are also good at running the same check before and after a deploy and reporting only the difference. Two things worth knowing before you start, both learned the hard way here. A green suite can sit over a code path that never ran. Tests that *drive* a control necessarily execute it; tests that merely assert the control *exists* never do. We shipped a panel this week that showed a permanent loading placeholder on first render — unit tests green, CI green, the full scenario sweep green, because nothing opened it in the state a customer first meets. Somebody looking at the deployed build found it in a minute. So include a scenario that opens the thing cold. And state *transitions* are where defects hide. Code tends to be correct in the state its author was standing in and wrong in a state nobody drove it through — a resize, a first load, a failure path. If your product has a responsive breakpoint or an offline mode, write a scenario that crosses it rather than one that sits on each side. To catch bugs early specifically: put the cheap breadth on a schedule so regressions surface without anyone deciding to look, and spend your judgement on the handful of scenarios where a silent failure would actually cost something — anything touching credentials, permissions, or data a customer cannot get back. Rank by what breaking quietly would cost, not by what is quick to write. The docs cover authoring scenarios and buckets in detail, and if you tell us what your riskiest surface is we can be more specific than this.

If you would like the exact Pragor controls behind that outline, QA — regression & defects walks through buckets, structured scenarios, running regression, screenshots, and defect triage. The practical place to begin is still small: choose the few customer journeys where a silent failure would hurt most, automate those first, and widen the suite from evidence rather than from a checklist.