Groma — Manual Test Runner

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 is shared by 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. ▸ 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. 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. YOUR LIBRARY ▸ Keep your test cases as files, in a folder you own Groma starts you with a built-in project, so there is nothing to set up. Point it 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 and no server of its own, 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 it: as one link, as an Excel workbook or as a PDF checklist. 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. ▸ 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 run, needs re-run, failed last time, skipped last time, notes logged, unresolved. 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. ▸ 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. ▸ Back up to your own Google Drive (optional) Any project can be synced with a folder in your own Google Drive, when you press sync and never in the background. Groma asks for the narrowest access Google offers — only the files it put there — and there is no Groma server in between. …