Groma

Precision-guided manual test runner. Author a flow as a shareable test case, then run it guided with a human as the sole arbiter.

Groma is a precision-guided manual test runner. A QA/PM authors a flow by walking the app once; Groma captures it as a test case that travels inside a link. Anyone that link reaches runs the flow guided, with Groma spotlighting each step — but the human stays the sole arbiter of every result. Nothing auto-passes or auto-fails. Author Click the Groma icon, pick the page to test from Home, and walk your app normally. Groma docks in the browser's side panel and captures the navigation plus a resilient, layered locator for every element you point it at (test ID → id → name → role → label → link → text → row-scoped → structural fallback), naming each pick from what it found. You write the checkpoint's instruction and expected result, and mark the ones that must pass before any release as critical. Nothing is captured until you ask for it — arm the picker, then click the element. It works on staging, prod, or localhost without touching your app's source, because the content script has the same same-origin DOM access your browser does. A microphone icon lets you dictate instructions and expected results instead of typing, using your browser's own speech recognition. A test case that is a variation on one you already wrote — the same checkout signed in, the same form with bad data — is duplicated with one click and edited, instead of walked again. The row's arrows put the test cases in the order they should run in. Stop halfway and the draft is kept for you; Home offers it back next time you open it. A step you have already written — a sign-in, a cookie banner, getting to the right account — is linked in from another test case instead of retyped, searchable by test case name or by the words in the step. It comes across as a copy, so editing it never reaches back into the test case it came from. Keep your test cases as files, in a folder you own Point Groma at a folder and every test case is saved into it as one plain JSON file. That folder is yours: put it in a git repo and your test cases get diffs, review and branches beside the code they describe; put it in a synced folder and they sync. Groma has no account, no sign-in and no server, and doesn't know or care which you chose. Connect more than one — a client's app, an internal tool, separate staging and production sets — and switch between them with a click. Groma's Home page lists everything in the active one, grouped by the test suite it belongs to, with a step count and a rough length, a read-only preview of what each test case asks a tester to do, the order the test cases run in, and every past run of each test case. Edit one and it opens in the side panel and saves straight back. Tick a few and either run them yourself straight away, or name the test suite, say which server it runs against, and Share builds a file for a tester that holds run links only — no edit link, so it can be forwarded freely. A test suite can carry a short brief — what this round is about, what the tester needs set up — written once instead of in every test case. A smoke test that maintains itself Mark the checkpoints that must pass before any release as critical, and Home gathers them into a Smoke Tests group: one short row per test case, holding only its critical checkpoints. It is worked out from the test cases every time, so there is no second copy to keep in step — edit the original and the smoke test follows. Run one row, run the whole smoke test in one go, or share it with a tester like any other test suite. See how a test suite is trending Analytics on any test suite reads its filed runs: the pass rate of the latest test cycle and how it moved, a pass-rate-by-cycle chart, where every step status landed, who ran it, each test case's record worst-first, and the steps that keep failing. Nothing is tracked for it — it is worked out from the runs already in your folder. Find one test case in a library of forty Search looks inside each test case, not just at its name — the description, the preconditions, and every step's instruction and expected result — and a row that matched on a step says which step, with your words marked. The same box replaces: rename a feature across every test case at once, previewed as an exact count of occurrences and test cases and confirmed before a single file is written. A filter answers the six versions of one question — what still wants attention: not reviewed, reviewed, never run, already run, failed last time, notes logged. And "Pages covered" works out from the test cases themselves every page they actually visit, and how many test cases and steps land on each, so thin coverage is a number rather than a hunch. Have somebody read it before you send it A test case is something a tester will be asked to follow, so it can be reviewed and signed off — a name, a date, optional comments — recorded on the test case file itself. It lapses by itself the moment the test case is edited afterwards, which is what makes it worth reading: an approval that outlives the thing it approved is worse than none. Home marks every test case that isn't reviewed — never signed off, or edited since — and counts both states in its filters. Groma has no accounts, so this is exactly what it looks like: a name on a form, next to a date. Check the test case still works before a tester finds out Apps change, and a locator frozen at capture can go stale silently. From the editor, open the app and walk the flow yourself: Groma checks each step's locator as you reach its page and flags what it can't find — including a locator that now resolves only by a weaker fallback, which works today and is one rename away from not. An element that several things now match is re-pointed by clicking the right one on the live app. One walk answers for every test case in the test suite. Groma only looks; it never clicks anything for you. Test the mobile layout without a second test suite Any step can be written for a screen size. Resize your own browser until the layout you want is on screen — the panel names the width as you drag — and press Set size on that step. When a tester reaches it, their window is put to that width, so one test case can walk them through a mobile drawer and then a desktop table. Nothing is emulated and no debugging permission is asked for: it is your real browser window at a real width. Log what you see Authoring is itself a test pass, so anything wrong you notice on the way has somewhere to go. Log an issue in one click, point it at the element it's about, and let the app's own uncaught errors be logged alongside. Issues never become part of a test case and never reach a tester — they copy out as Markdown for a bug tracker, and file into the connected project as a versioned record, read back on Home as one bucket for the whole project ("Project Issues Logged"). With no project connected they download as their own file beside the test cases. Run A tester opens the shared link and the app opens in an ordinary tab, with each step beside it in the browser's own side panel and the target spotlighted in place. Pass, Fail or Skip — one click each (or Alt+P / Alt+X / Alt+K), the step's own note box as the comment, and a screenshot kept for a Fail. Skip is for a step that could not be attempted at all — no test card, a feature switched off in this environment — and is the one status that requires a reason; it is counted apart from the pass rate, so one untestable step doesn't drag a clean run down, and it is there so nobody has to fail a step that isn't broken. Nothing pauses: Terminate leaves on any step, keeping every status already given and counting the steps below it rather than judging them. A run survives a page reload, and a closed side panel, and resumes on the step it left off — and a tester who has to stop for the day parks the whole run (or a whole "Run all") with one click and picks it back up on the step they left, even after restarting the browser. Running a whole set in sequence ("Run all") lets the tester tick which of the test suite's test cases actually apply this time and reorder them first, then walks them with nothing to click in between and ends with one archive download. If it's interrupted instead — a closed tab, a crash, a declined download — the finished reports stay parked locally and the toolbar icon badges to say so, so nothing already tested is silently lost. Anything saved — an unfinished draft, a parked run, undelivered reports — is offered back on Home, one click from the toolbar icon. Share Authoring produces a standalone HTML document listing every test case — no server, no sign-in. Each test case's title is a run link carrying the target URL and the test case itself, compressed into the link's fragment, so the test case never touches a server. A "Run all" link walks the whole set in sequence, an edit link reopens the set for revision, and one more link downloads it as a real .xlsx workbook for stakeholders who live in a spreadsheet. Anyone who opens a run link can run it: with Groma installed it runs in place, and without it the hosted run page handles it. A test suite has one base URL — the address its test cases run against. Set it as you share (or while authoring, when you're exporting a session directly) and every link in the test suite is pointed there, so the same set can be sent out against staging one week and a review box the next by changing one field and sharing again. Only the server part of each URL moves; paths, steps and locators stay exactly as captured. Testers are never asked to pick a server. Report A completed run rolls up into a standalone HTML report with per-step statuses and notes, tiles across the top that filter the run down to just its passes, failures or skips (a skip tile only appears when something was skipped, and skips are left out of the pass rate rather than counted against it), a screenshot of every step that failed — and only those, so a picture in a report always means a failure — and a video of the run, sampled locally from the tab, so there is no screen-share prompt. A reviewer can watch it straight through skipping the pauses, or press "Play this step" on any step to see just that stretch. The report embeds the test case, so it's re-runnable: reopen it and go again. A failed step also carries what the app printed to its own console and the requests it made while the tester was on that step — method, URL, status and timing for every request, and for the app's own fetch/XHR calls the headers, payload and response body too — so a developer reads the failure without having to ask for a reproduction. A "Run all" saves one archive instead: a contents page over a folder per test case. With a folder connected, each run is filed into it the moment it ends, so nothing is lost to a forgotten Save, and every past run of a test case is listed on Home to reopen, download, save as a PDF or delete. Why manual, not automated? Some things only a human can judge — visual polish, confusing copy, a flow that's technically correct but feels wrong. Groma isn't trying to replace Playwright or Cypress; it's built for the QA/PM pass those tools don't cover, and it can reuse the same data-testid your automated suite already relies on, so the two never drift apart. No package, no backend, no accounts. Groma is only a browser extension. There's nothing to install in your app, nothing to sign into, and no data leaves your browser except what you explicitly export or share.