Help

Anything you export from Test Dossier you can drop straight back in — a whole project or a single case, with screenshots. Use it to move work between devices, recover a backup, or seed a new project from an old one.

1. Export first: All Tabs ZIP for a whole project, or Download Backup / ZIP Bundle for one case. The ZIP carries a manifest.json plus each case's data.json and screenshots/.
2. Open Import Test Cases and drop the .zip (or a single backup .json).
3. Test Dossier recognises its own export and switches to restore — Test Case IDs, verdicts and evidence are preserved, not re-parsed into new cases.
4. Pick the destination: a New project (the default — keeps the original Test Case IDs) or an existing one. Restored cases land in the project's library, not as open tabs; open them from All tests.

Use when you already have a structured list of test cases — from a spec doc, Confluence page, Google Sheet, or an AI-generated table — and don't want to type each one.

1. Click Import Test Cases in the top bar.
2. Paste a markdown table. Columns are matched flexibly: the parser recognises Scenario / Action / What to test / Step description (becomes Action), Test Data / Input / Condition / Precondition (becomes Test Data), and Expected / Result / Outcome / Verify (becomes Expected). A TC or # column is auto-ignored — steps are numbered by the tool.
3. Optional: include an H1 or H2 heading above the table — it becomes the new tab's Summary.
4. Optional: include H3 section headers between multiple tables — each step gets prefixed with its section name (e.g. [Productkeuze] Scenario description).
5. The preview below the paste area shows how many steps will be created and which sections were detected. If something looks wrong, fix the markdown and re-paste.
6. Click Create Tab from Import. A new tab opens with all fields pre-filled — you can now skip straight to execution and evidence capture.

Export

Best when your Jira ticket is a story or bug and you're posting test evidence alongside it.

1. Click ZIP Bundle (current tab). A zip file downloads.
2. Unzip it — you get evidence.html, evidence.jira, evidence.md, evidence.txt, evidence.junit.xml, README.txt, a data.json portable snapshot, and a screenshots/ folder.
3. In Jira, open the ticket. Drag all files from screenshots/ into Jira's attachment area.
4. For Jira Server / Data Center: open evidence.jira, copy, paste into a new comment.
5. For Jira Cloud: open evidence.md and paste — or paste evidence.jira using the comment menu's Paste as wiki markup option. Image references auto-resolve to the attachments you just uploaded.

Use when you want the test to become a reusable case in your TestRail library.

1. Click TestRail CSV + Screenshots. Choose current tab or all tabs.
2. In TestRail, open the target suite and click the Import icon. Choose Import from CSV and upload cases.csv.
3. On Row Layout, pick Test cases use multiple rows. Set Title as the column that starts a new case.
4. Column mapping should auto-fill (Section, Title, Steps, Expected Result, etc.). The Section column reads from your TD suite name, so a suite-organized project round-trips into TestRail's folder hierarchy without manual sorting. Cases without a suite land in TestRail's root section.
5. Open each imported case and attach files from the screenshots/ folder to the right steps.

1. Click PractiTest CSV + Screenshots.
2. In PractiTest go to Settings → Import & Export → Import Tests and Steps.
3. Upload cases.csv. Ensure UTF-8 encoding is selected.
4. Columns match PractiTest's documented field names — most auto-map. Verify Step Position maps correctly (it's how new tests are detected).
5. After import, attach screenshots to individual steps.

Every evidence ZIP includes evidence.junit.xml — the standard JUnit XML format. Import it natively into TestRail, PractiTest, Xray, Allure, BrowserStack, CircleCI, Jenkins, GitHub Actions, GitLab — anything that ingests JUnit. One <testcase> per step; failures map to <failure> blocks. Step detail travels as both <properties> (machine-readable for tools that key on attribute paths) and <system-out> (human-readable for tools that surface output text). Drop-in replacement for hand-rolled vendor-specific exporters when your platform speaks JUnit.

POST your CI results to /api/ci/ingest with a project access token (CI ingestion enabled). If a test carries its own structure, TestDossier turns the run into a draft test case you review once, then freeze — you never write the documentation by hand. Steps come from the structure you already wrote, projected deterministically. We do not invent steps with AI.

Two shipped ways to carry that structure:

• Playwright — wrap work in test.step('action → expected', …). The → (or ->) splits action vs expected; a [TD:<id>] in the test title is the stable identity. Send with X-CI-Format: playwright.
• JUnit (any runner) — emit per-testcase <properties>: td:step:1:action, td:step:1:expected, td:step:1:result, and td:dossier for stable identity. Send as Content-Type: application/xml (no X-CI-Format needed for JUnit).

curl -X POST https://testdossier.com/api/ci/ingest \
  -H "Authorization: Bearer $TD_TOKEN" \
  -H "Content-Type: application/xml" \
  --data-binary @junit-results.xml

The Export to Tool ▾ menu in the output panel ships built-in mappings for the most common test management plugins beyond TestRail/PractiTest. Each one writes a cases.csv with columns matching the vendor's documented import format, plus a screenshots/ folder and a README.txt with vendor-specific import steps.

• Zephyr Scale — Atlassian Marketplace plugin (formerly TM4J). Step-by-step test script format.
• Xray Cloud — Atlassian Marketplace plugin. Manual test type, one row per step.
• Qase — modern, SMB-friendly. One row per case, steps in a single cell.
• Azure DevOps Test Plans — Microsoft work-item grid format.
• TestLink — open-source test management.

If your test management tool isn't in the menu — or if your team uses a custom CSV schema — open Export to Tool → Custom mapping. You can:

• Pick any built-in preset, click Clone & Edit, and tweak it.
• Build a mapping from scratch: add columns, set headers, and drop in {{token}} placeholders for any field. The token picker shows everything available (case-level: {{title}}, {{summary}}, {{preconditions}}, etc.; step-level: {{step.action}}, {{step.expected}}, {{step.result}}, {{step.attachments}}, etc.).
• Toggle row mode between "one row per case" (case columns blank on continuation rows — TestRail/Zephyr style) and "one row per step" (case columns repeat — Xray style).
• Choose CSV or Excel output.
• Save Preset stores it in your browser. Export Preset JSON shares it with teammates — they can Import Preset JSON to use the same mapping.
• The Live Preview pane shows the first 2 rows so you can see the result before downloading.

Use to move a tab between machines, recover from a browser wipe, or share a draft with a teammate.

1. ⬇ Download Backup downloads the current tab as a single .json file (including screenshots as embedded base64).
2. ⬆ Restore Backup reads a previously-downloaded backup and opens it as a new tab alongside your current ones — nothing is overwritten.

Work on multiple tickets in parallel. Click + to add a tab; × closes one. Use Close all tabs in the toolbar's More-actions menu (or the command palette) to bulk-close — same archive behavior. Each tab has its own state. Closing a tab with content keeps it findable under Test Cases so you can restore it — nothing is lost. Empty tabs close silently with no prompt.

Every test case carries a tags field (the + tag chip area at the top of the case form). Tags are workspace-shared and free-form — typical use is "smoke", "regression", "payments", "nightly". Press Enter / , / Space to commit a tag, or click outside the input. Click the × on a chip to remove.

Tags drive a filter that narrows both surfaces where tabs / cases are listed:

• Tab bar — when a filter is active, only tabs whose tags include every selected tag stay visible. Active filter pills render at the start of the strip, each with × to remove individually. The active tab is never hidden (so the editor never disappears under you).
• Test Cases modal — two inline pill rows: Result: (Passing / Failing / Blocked / Skipped / Pending — multi-select OR) and Tags: (every tag in scope — multi-select AND across tags). The two predicates AND together, so picking #smoke + Failing shows only failing smoke tests.

Setting / changing filters lives in the modal. The tab bar reflects state read-only; clicking a pill's × there clears that one predicate. Empty result combinations show a centered "No tests match X — Clear filter" panel so you know the filter is active and what to undo.

Multi-select rows via the row tickboxes (or Select-all per section). A footer toolbar offers, depending on what's selected:

• Close N tabs — soft-close selected open tabs (recoverable; same as the × on the tab strip).
• Delete N — permanently remove selected closed-tab drafts.
• Move to suite — change the suite for selected cases (live PATCH for open tabs, recorded-on-restore for drafts).
• Set priority — apply Critical / High / Medium / Low / Clear to every selected case.
• Send to workspace… — copy selected cases into a workspace project (originals stay; switch context after).

A single "N selected" chip at the start of the toolbar carries the count so action labels stay short. Hidden when nothing is checked.

Every test case gets an auto-generated, stable ID that appears at the top of the form once you start filling it in. It's read-only — the app generates it once and it never changes. Use it to refer to a specific test case in Slack, Jira comments, or anywhere else. Click next to the ID to copy.

Why it matters: two test cases for the same ticket (e.g. happy path vs. error path) can be told apart by their Test Case IDs even though they share the ticket key. The ID is also embedded in every export (ZIP filenames, CSV/XLSX columns, README) so re-imports preserve the link to the original.

Sharing with teammates: when you export a backup and a teammate restores it, they see the same TD-xxxxxxxx you do. Both of you can refer to the case by its ID and mean the same thing. Only on the rare event of a true ID collision in their workspace will the import be renamed (with a notice).

Limit: the ID identifies a logical test case, not a version of it. If both you and a teammate edit the same case independently and re-share, you'll have two diverged copies with the same ID — there's no built-in merge resolution. For real collaborative editing, use the Pro tier's cloud sync where the server is the single source of truth.

Every change saves to your browser's local database (IndexedDB) after about half a second. The indicator in the top bar shows "✓ Saved" when current. Closing the page and reopening restores everything.

Paste with Ctrl+V, drag files, or click the dropzone. Images compress automatically to keep test cases small. Click any image to view full size. Click the icon to open the annotation editor.

Annotation toolset:

• Rectangle / arrow — drag on the canvas to draw. Stroke color follows your brand accent (or red if you're using the default). Right-click any shape to delete.
• Blur / redact — drag a rectangle, then pick blur intensity or solid-fill mask. Use for masking PII (emails, names, customer IDs) before sharing a screenshot externally. Redaction is destructive — the underlying pixels are replaced, so re-opening the image won't reveal what was masked.
• Undo / Redo — the editor keeps a per-image stack. Closing the editor commits; reopening starts a fresh stack.
• Save — re-uploads the annotated copy with a new hash (R2 dedupe still works — only the changed bytes count toward storage).

The original (pre-annotation) image is not retained — annotations replace the file in place. If you need to keep the unannotated version, duplicate the image first (click the ⎘ icon).

The compact table format used in Jira / Markdown exports carries an Evidence column for a step's screenshots. The column hides entirely when no step on the tab has any evidence — empty cases don't render a permanently blank column. In CSV / XLSX exports the same column lists folder-prefixed paths (screenshots/img.png) so the destination tool's importer (or the human walking the unzipped tree) can find every artifact verbatim.

+ From Template offers pre-shaped steps (Login, Form submission, API call, Navigation, Permission check, Error handling). Some pre-fill the Test Data field with useful placeholders.

Shared test data (environment config, test users) goes in the Specification group's Test Data field. Step-specific data goes in each step's Test Data field. Both support key: value lines — keys get auto-bolded in the output.

Three preview tabs: Jira Markup (wiki syntax for Jira Server/Data Center and older Cloud instances), Markdown (Confluence, GitHub, general use), and Preview (rendered HTML — closest to what Jira will show).

A Style: toggle sits next to the format tabs and switches how your test run gets rendered:

• Detailed (default for most tabs) — a summary table on top, then one per-step detail block per step with Action/Test Data/Evidence and side-by-side Expected ⟋ Actual. Best for 1-15 step test runs where each step deserves its own visual block.
• Compact (auto-selected for imports with 15+ steps) — one wide scannable table with every step's details in a single row. Failed and blocked steps with defect notes get a Defect details section below the table. Best for long verification matrices (20-50+ steps) where a wall of per-step tables would be unreadable.

The choice is per-tab and persists — a 3-step bug-repro tab can stay detailed while a 45-step feature verification tab is compact. The toggle affects all three output formats (Jira, Markdown, Preview).

When you set a step's result to FAIL or BLOCKED, a Defect Details field appears below. Use it to describe what went wrong — error messages, reproduction conditions, timing, console logs, suspected cause. Click Copy as Bug Ticket to copy a pre-shaped bug ticket body (Summary, Steps to Reproduce, Expected, Actual, Environment) that you can paste directly into a new issue.

By default, Steps to Reproduce includes only the failed step itself — most bugs are self-contained ("clicking submit returns 500") and prior steps would be noise. When the failure depends on context (e.g., "after navigating through 3 pages, the form clears"), tick Prior steps as repro path in the dropdown — the body then includes every PASS/FAIL step before the failure as a numbered chain, with the failed step bolded and annotated "← failed here". Skipped steps are omitted (intentionally bypassed); blocked prior steps are omitted (didn't run). Like the format choice, this toggle persists for the session.

The format dropdown (▾) next to the button picks the markup: Markdown (GitHub, GitLab, Linear, Notion, Jira Cloud), Jira wiki (Jira Server / Data Center), or Plain text. The default follows your output-format selector at the top of the page; the first time you pick something different from the dropdown, that choice sticks for the rest of the session — every subsequent step's button inherits it, so you don't have to re-pick per step. Closing the tab resets back to the global default.

If the step has screenshots, a Download screenshots button bundles just this step's images into a small zip — drag the files into the bug tracker after pasting the body.

In any textarea you can use four Markdown-style shortcuts:

• **bold** → emphasis in the output
• \`code\` → inline code (good for error messages, IDs, API paths)
• Lines starting with - or * → bullet list
• Lines starting with 1. , 2. , etc. → numbered list (renumbered automatically)

These render properly in Jira markup, Markdown, and the rendered preview. In TestRail/PractiTest CSV exports they stay as literal characters (readable but not styled, since those tools import as plain text).

Note: Lists only render as proper lists in block fields (Summary, Preconditions, Defect Details, etc.) and not inside the per-step Expected/Actual table cells — Jira's table cells don't support list markup. In those cells they display as bulleted/numbered lines, which is still readable.

Identity & Links is always visible. Classification, Specification, Run / Execution, and Notes collapse by default. They auto-expand when they contain content. Explicitly collapsing a group with content makes that choice stick for the tab. Build / Environment / Browser / OS aren't on the case form — they're captured per execution via the Log Snapshot dialog.

Closing a tab with content keeps it under Test Cases so it's never lost. Open that modal to see every test case in the project — currently-open tabs are marked, closed tabs have a Restore button. Multi-select tickboxes drive bulk actions: Close N tabs (recoverable — same as the X on the tab strip) for selected open tabs, Delete N test cases (permanent) for selected closed tabs, plus Send-to-workspace and Move-to-suite when those apply.

Projects group your test cases by client, app, or sprint. Click the project switcher pill in the top bar to switch between them or create new ones.

• Free / anonymous: unlimited local projects. They live in this browser only — a "Local" pill marks each in the switcher. Upgrade to Pro to sync them across all your devices.
• Pro: unlimited cloud-synced projects. They appear on every device you sign in to.
• Workspace: projects scoped to the workspace are visible to every member.

Archive a project from the project menu (× hover button). Archived projects move to the collapsed Archived section; you can restore them or permanently delete with a typed-name confirm.

Move a project between Personal and a workspace by right-clicking the project in the sidebar tree and choosing Move… (workspace projects) or Move to workspace… (personal projects). The project moves with all its test cases, runs, and history. Auth rules:

• Personal → workspace: the project's creator, who must also be a member of the destination workspace.
• Workspace A → workspace B: an owner of A who is also a member of B.
• Workspace → Personal: an owner of the source workspace.

Different from Send to workspace, which copies selected test cases into an existing destination project. Move relocates the whole project entity.

Upgrading from free to Pro: when you upgrade, a one-shot prompt offers to move your local projects to the cloud. Each migration creates a server project, re-tags + uploads your tabs, and clears the local entry. You can skip and migrate later from the project switcher.

Turn raw ticket IDs (the Primary Ticket field on a case, Linked Tickets chips, step defect notes) into clickable links to your Jira / Linear / GitHub issue tracker. Set a template like https://yourorg.atlassian.net/browse/{id} and every PROJ-123 rendered anywhere in the case becomes a one-click navigation to its tracker.

Two precedence levels, so global defaults coexist with per-project overrides:

• User global — applies to every project you can access. Set from the project menu → Tracker URLs… → top row. Survives device + workspace switch.
• Project override — set on a specific project when its tickets live somewhere different from the rest of your work (e.g. one client uses Linear instead of Jira). Falls back to the global when blank.

Templates support {id} and {ticket} as the placeholder. A malformed template (no placeholder) renders the ticket as plain text rather than breaking the link — soft-fail by design.

Save a step once, reuse it across many test cases. Common use: "Sign in as admin user", "Reset the seed data", recurring assertions.

• Save: click the 📎 icon in any step's action bar — the step's action / expected / test data become a library entry.
• Insert: click 📎 From Library next to + Add Step and pick. The inserted step is linked back to the library entry (visible as a "Library: name" pill on the step header).
• Propagation: when you edit the canonical library entry, every linked step updates on next render. Editing a linked step's fields locally detaches it from the library.
• Manage: sidebar Tools → Step Library. Search, edit, archive.

The Record a session button bridges to the TestDossier Capture browser extension — recording happens in the extension's side panel, not in the app (a browser can't open an extension panel for you). If it's installed, the button shows how to open the panel; if not, it points you to install it.

• What it captures — every click, keypress, form entry, navigation, plus the network calls, console output and screenshots behind them. It's deterministic: a captured event stream becomes readable steps with no model call and no AI involved.
• What you do — open the panel, name a new test (or search/paste a TD-… id to update an existing one), walk through the flow, then Stop and submit. The draft lands in this project as a test case you review.
• What it does NOT decide — the recorder assigns no verdict. Expected Result is left blank for you to confirm, every step starts PENDING, and an observed error (a non-2xx response or console error) is surfaced as a note to look at — never pre-judged as a pass or fail.

Recording stops when you click Stop in the panel. Nothing leaves your device until you submit.

Free vs Pro. Free includes unlimited local capture. Captured screenshots stay on your device: the server holds the bundle just long enough for the app to drain it into your local store on next open, then deletes it (7-day TTL). If too many captures are waiting undrained, open the app to save them before recording more. Pro adds cloud-synced evidence and the extension's CI sibling for pipeline runs.

Before you hit Record, the panel lets you choose how screenshots are taken for the session. The setting is per-recording (it sticks across sessions) and shows under Screenshots.

• Auto (default) — a keyframe is captured for you once the page settles after each action: it waits out the network, and any scrolling, so the shot shows the result of the step (the landed, rendered page) rather than the instant you clicked.
• Manual — nothing is captured automatically. You take every frame yourself with Capture, so the evidence is exactly the moments you chose and nothing else. The recording header reads "Manual capture" so the mode is clear.

The Capture button is available while recording in both modes, and there's a keyboard shortcut for it (default Ctrl/Cmd+Shift+Y, rebindable at chrome://extensions/shortcuts) that works even while your focus is on the page — handy for grabbing a transient state, like a success toast, that an automatic shot might miss.

• In Auto — Capture adds a frame to the current step alongside the automatic one; it never replaces it, so you don't lose the settled-page shot.
• In Manual — Capture is the only way a frame is taken.

The recording is buffered locally and never leaves your browser until you press Submit, but a captured case can be shared publicly — so the extension redacts on the way in, not just on the way out.

• Password fields — never captured. Any <input type="password"> value is masked before it enters the buffer.
• Known-sensitive values — fields whose name, id, or autocomplete attribute matches password / token / secret / OTP / CVV / card / SSN / PIN are masked too. This now covers <input>, <textarea>, and rich-text (contenteditable) fields — so an API-token textarea or an OTP entered into a custom editor is redacted the same way.
• Network metadata only — method, URL, status, timing. Request and response bodies are never captured, so a JSON response carrying a token or PII can't leak into the case.

Screenshots are pixels, not fields. Field-level masking redacts values you type, not what the page renders. Anything visible on screen at the moment of capture — account names, real customer data, an open chat panel — is in the screenshot. Use the panel's Pause button before doing anything off-record on the page, and review each thumbnail before submitting.

If you start a recording with the Network & errors toggle on but see a yellow notice in the side panel that reads "Network/error capture unavailable on this tab", it means the extension's network/console backend couldn't attach to the tab. The usual cause is that DevTools is already open on that tab (DevTools is a CDP client; another one — including ours — can't attach at the same time). Less common: a remote-debugger session (Playwright/Selenium driving the browser), or a Chrome internal page (chrome://) that isn't debuggable.

The recording continues — DOM actions and screenshots are still captured — but network metadata and uncaught JavaScript errors are NOT. The submitted draft case carries a one-line note in its Notes field so a reviewer doesn't read "no console errors" as "no errors occurred."

To get the network/error layer back, close DevTools (or stop the remote driver), discard the current session, and start a new recording.

Suites are folder-style groupings of test cases inside a single project. Useful when a project has 40+ cases and you want them sliced by feature area (Auth / Checkout / Admin) or by what you re-run together (Smoke / Regression / Nightly). Each test case lives in at most one suite; "Uncategorized" is the bucket for cases without one.

• Create: Test Cases modal → suite dropdown → + New suite, or set the Suite field on a case directly.
• Move cases: bulk-select in the Test Cases modal → Move to suite dropdown. Open tabs are PATCH'd live; closed drafts get the new suite recorded for next restore.
• Filter by suite: Test Cases modal shows a Suite: dropdown that scopes the list to one suite at a time. Resets to "All suites" each time the modal opens.
• Plan integration: Test Plans render their items grouped by suite, with a "common setup" note per suite that stays with the reusable plan. A Smoke suite's setup ("seed admin user, clear cache") shows once at the top of its section in every plan run.

Suites round-trip via the bundled export presets — the TestRail Section column reads from the suite name, so a suite-organized project lands in TestRail with the same folder shape.

A Test Run is a multi-case execution session — pick the cases you want to run for a build, work through them, and the run tracks which ones have been executed, which are still pending, and what each one's latest result is. Different from a Test Plan (the static list of cases that should be in this regression suite) and from Snapshots (the per-case execution records). A run is the session; the snapshots it produces are the evidence trail. Open from sidebar Library → Test Runs.

Lifecycle (intentional friction so "closed" feels final):

• Open — fresh run, cases assigned, nothing run yet. Click Start running to move on.
• In progress — actively executing. Logging a snapshot against a case in this run updates the run's per-case latest result. Click Mark completed when finished.
• Completed — execution done, results final. The run is still editable (reopen if needed). Click Close run to seal it — no further snapshots can land. Confirmation dialog reminds you the seal is reversible.
• Closed — read-only seal. Useful when you've sent the results to a stakeholder and want the record locked. Reopen moves it back to In progress if you need to amend.

Re-test failed: when a completed (or closed) run has any FAIL / BLOCKED cases, a ↻ Re-test failed button creates a new run pre-seeded with just those cases. The new run inherits the original's name with a "Re-test:" prefix. Cuts the regression loop down to one click instead of hand-picking cases.

Filters: the runs list supports search by name, status filter (All / Open / In progress / Completed / Closed), and a free-form Build filter so you can pull up "every run against build 2.3.1" without scrolling. State persists across modal opens.

Group test cases into a sprint regression or release checklist. Plans define scope; Test Runs capture the build, environment, assignee, status, and execution results. Open from the sidebar → Plans.

Free gets unlimited plans inside its local-only projects (stored in this browser, alongside the local projects themselves). Pro adds cloud sync and workspace sharing. Workspace plans count against the workspace's tier, so a free personal account inside a Pro workspace inherits the cloud plan workflow.

Common pattern: keep one "Sprint regression" plan as the canonical checklist, then click Run this plan whenever you need a new execution for a build or environment.

Plan results vs dashboard results — they can disagree on the same day. A plan row uses latest-run-wins ("did we get this case green for the release?"); the dashboards (Insights, Hotspots) use any-fail-in-day ("is anything broken on this case today?"). If a chain failed at 03:00 and a tester verified PASS at 14:00, the plan shows PASS (sign-off achieved) and the dashboard shows FAIL (something flaked earlier). Both true; intentional split, not a bug.

A disposable email address that delivers right inside the app. Drop it into a signup form, password reset, or magic-link flow — messages arrive within seconds. Open from sidebar Tools → Test Inbox.

• Personal inbox (Pro): pick a prefix like tester and you get tester.<random-token>@inbox.testdossier.com. Random suffix prevents enumeration; the prefix is shown in the UI.
• Workspace inbox (workspace owner): a single shared address visible to all workspace members. Useful for testing flows the whole team needs to verify.
• Rotate: change the prefix or suffix any time — old mail to the previous address bounces, past messages stay readable.
• TTL: messages auto-delete after 7 days.

Every case carries an optional Test Type. The label is yours — picked from a dropdown of conventional categories, used by exports (TestRail / PractiTest Type column, JUnit <property name="test-type">) and by Project Insights to slice runs by category.

• Smoke — quick happy-path proof that the build loads end-to-end.
• Functional — does the feature work as specified. The workhorse type for most cases.
• Regression — covers a specific change plus the adjacent surfaces that often break with it.
• End-to-End — full user journey across services / pages. Distinct from Integration (which is service-to-service).
• Integration — two or more services / modules talking. Often a step deeper than functional.
• UAT — user acceptance, run by stakeholders before sign-off.
• API — endpoint behaviour: status / payload / response shape.
• Security — auth, token handling, permission boundaries, OWASP-style cases.
• Accessibility — keyboard nav, focus order, ARIA, screen-reader output.
• Performance — latency, throughput, load behaviour.
• Exploratory — unscripted poking around; record what you found.
• Other — escape hatch for anything that doesn't fit.

Test Type is always a manual pick — choose whichever category fits.

Hook your CI pipeline (GitHub Actions, GitLab CI, Jenkins, anything that can curl) into TestDossier. Each test execution from CI lands as a snapshot on its test case — and if no matching case exists yet, the run creates one as a draft for you to review. CI does the writing; you sign off.

1. Open the project menu in the top bar → Access tokens….
2. Pick a label (e.g. "GitHub Actions"), leave CI ingestion ticked, and create a token — copy the plaintext immediately, we only show it once.
3. POST your test report to /api/ci/ingest with Authorization: Bearer <token>. Three formats accepted:
   • Generic JSON: { "tests": [{ "name", "ticket", "dossier_id", "result", "duration_ms", "failure_message", "steps" }] }
   • JUnit XML: send Content-Type: application/xml with the standard JUnit report. Cypress, Playwright, pytest, Mocha, Jest all emit this when configured.
   • Cypress / Playwright JSON: native reporter output with the header X-CI-Format: cypress or playwright. Carries retry attempts, screenshots, and traces — richer than JUnit.

How a CI run finds its test case (resolution order, most-specific first):

1. dossier_id on the test → exact match against the case's stored ID. Stable across renames; survives suite moves. Recommended for new wire-ups.
2. dossier_id → alias index. Imports (TestRail CSV, Zephyr Scale, Xray Cloud) auto-register the source-tool ID as an alias, so existing test code keeps pointing at the right case without rewrites. Example: a TestRail case imported as C42 resolves when CI sends dossier_id: "C42".
3. ticket exact match.
4. Test signature — an exact match on the test's file + suite + title. This is how a run with no explicit id still finds the same case on every re-run, with nothing to annotate.
5. Test name contains the case's summary (substring, ≥4 chars) — a loose last-resort fallback.
6. Miss → auto-create a reviewable draft. Any identifiable test — a marker, or just a name/file — auto-creates a draft case assigned its own native TD-<n> id; steps from the payload become the definition and the run logs as the first snapshot. Surfaces in the Project insights "Needs attention" banner. Only a genuinely anonymous test (no id, no name, no file) stays an "untracked" snapshot — visible in Snapshots, no case.

Send rich steps from Playwright: the wrapper at dossier-playwright.ts (single file, copy-paste, ~180 LOC, no npm install) exposes dossier.id('LOGIN-001').step('action', 'expected', fn). Each step() call becomes a row in the auto-created draft — so first-run drafts arrive already structured, not as one-step stubs you have to flesh out.

Build / branch metadata: pass X-Build and X-Branch headers, or include them as body fields in the generic JSON path. They show up on the snapshot row and the share page.

Idempotency: pass X-CI-Run-Id (e.g. ${{ github.run_id }}_${{ github.run_attempt }}) so retried CI workflows don't produce duplicate snapshots. Same run_id on a re-upload returns the original ingest's summary instead of inserting again.

Unbounded runs (paging). One request accepts up to 1000 tests — over that it returns 413 (never a silent truncation). For a larger run, page across requests: keep the same X-CI-Run-Id and send a unique X-CI-Page-Id per page (a 1-based counter). Idempotency then keys on (run, page) — re-sending a page replays its summary, while a different page of the same run accumulates. Slice a generic-JSON { "tests": [...] } report into 1000-test pages and POST each.

Definition vs execution — never silently overwritten. Once you sign off a draft, CI never rewrites the test's steps / expected on a subsequent run. New runs append snapshots; if CI reports a different definition for a reviewed case, that surfaces as a drift banner you can choose to apply — never a silent change to your reviewed docs.

GitHub Actions example. Drop this into .github/workflows/cypress.yml — runs nightly + on every PR, uploads results to TestDossier:

name: Cypress
on:
  schedule:
    - cron: '0 2 * * *'    # nightly 02:00 UTC
  pull_request:
  push:
    branches: [main]
jobs:
  cypress:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - name: Run Cypress
        run: npx cypress run --reporter json --reporter-options output=cypress-results.json
        continue-on-error: true            # upload even on test failure
      - name: Send results to TestDossier
        if: always()
        env:
          TD_URL: https://testdossier.com
        run: |
          curl -X POST "$TD_URL/api/ci/ingest" \
            -H "Authorization: Bearer ${{ secrets.TEST_DOSSIER_CI_TOKEN }}" \
            -H "Content-Type: application/json" \
            -H "X-CI-Format: cypress" \
            -H "X-Build: ${{ github.sha }}" \
            -H "X-Branch: ${{ github.ref_name }}" \
            -H "X-CI-Run-Id: ${{ github.run_id }}_${{ github.run_attempt }}" \
            --data-binary @cypress-results.json \
            --fail-with-body

Three things that trip people up:

• continue-on-error: true on the test step + if: always() on the upload step — without both, a failed Cypress run skips the upload (the failures you most want logged).
• X-CI-Run-Id with ${{ github.run_id }}_${{ github.run_attempt }} — idempotency key, so retried workflows dedupe instead of duplicating snapshots.
• --fail-with-body — curl exits non-zero if the ingest is rejected (401, 413, etc.). Without it, a token problem silently looks like success in the workflow log.

For Playwright: swap the run command to npx playwright test, change the header to X-CI-Format: playwright, and use @playwright-results.json. For JUnit XML: drop the X-CI-Format header, set Content-Type: application/xml, and POST the XML directly. Everything else stays the same.

When CI auto-creates a case (resolution path #5 above), it lands as a draft: visible in the project canvas with a small review pill, counted on the Project Insights "Needs attention" banner, and never published to share links until a human signs off. The review surface is the same canvas — open it from the sidebar or from the banner's "N CI drafts to review" chip.

The queue: split layout — list on the left auto-advances; preview on the right shows action / expected / steps for the selected draft. Navigation happens inside the canvas — no tabs open until you hit Edit in tab, the escape hatch for cases that need real editing.

Filters narrow large queues:

• Failed — drafts whose latest snapshot is FAIL. The bugs to triage first.
• Needs authoring — the stub bucket: under 2 steps, or any step's expected text is under 8 chars or a TODO / placeholder. CI gave you a skeleton; a human has to flesh it out before it's trustworthy.
• Clean — the inverse, ready-to-bulk-approve set: 2+ steps, every step has real expected text, and the latest CI run isn't failing. Filter here, then Mark all reviewed with confidence.

Bulk approve is the dominant primitive at scale. The "Mark all N reviewed" button confirms before flipping — at 500 drafts a careless click would be expensive. A safety net catches you: every reviewed case shows an undo pill on its row for the next 24 hours. One click reopens it for refinement.

Keyboard: J / K next / previous, A approve current (auto-advance), Shift+A bulk approve the active filter, E edit in tab, Esc close. Clearing a 500-draft queue is a few minutes with the keyboard.

Audit trail: every approval writes an event row (who, when, was it part of a bulk sweep). Workspace teams can answer "who signed this off?" without digging through tab history.

Per-project health dashboard, opened from the project menu → Project insights. Shows the project's pass rate, run count, last-run timestamp, and number of test cases at the top, then three stacked bar charts on a single row — Manual runs / day, API Automation runs / day, CI runs / day. Charts split because a manual fail (a human noticed something), a CI fail (could be flake / timeout / infra), and an API automation fail (cron found a regression) read as different stories; KPIs stay unified because the project's overall health is one number.

"Needs attention" banner: sits above the KPI cards and surfaces drafts awaiting review + cases that haven't appeared in a CI run for 14+ days. Each count is a click — jumps you straight into the review canvas (or the stale-cases filter) so triage is one move from the dashboard. Banner hides itself when there's nothing to attend to.

Per-test-case-per-day rollup. The chart counts test cases as the unit, not raw fires. Multiple snapshot rows on the same day fold into one logical row per (test case, day, tester) with a fail-priority rule (any FAIL → the test case is FAIL for that day). Hotspots and the share-page snapshot use the same rollup.

Chart ⇄ List toggle: a pill in the modal header flips the body between the charts and a day-by-day list naming every failed test case. Click a chart bar → flips to List, scrolls to that day. From a failed row: manual fails open the test case (where you investigate); CI fails open a CI Artifacts panel with stack trace, retry attempts, and attachment paths. Unmatched CI runs (not linked to a test case) carry an "UNTRACKED" chip.

Range selector in the header (7 / 14 / 21 / 28 / 30 / 60 / 90 days) — defaults to 30 days. Range and view choice persist across sessions.

Inside a workspace, a small green dot on the tab bar shows when a teammate is viewing the same test case. Hover the dot for the email list. Heartbeat polls every 10s while the page is visible, pauses on hidden tabs.

Sidebar Activity shows a chronological stream of what's happening in the workspace — runs logged, test cases edited / cloned / restored, comments posted, plans created. Each row links back to the source so you can jump from "Alice logged a FAIL on PROJ-123" straight to that run in History.

Use it as a low-effort standup feed: open the workspace in the morning and skim the feed instead of asking "what changed yesterday?"

From the History modal, multi-select runs and click Share as report — TestDossier mints a read-only link bundling the selected runs into a single page. Optionally protect with a password (the link won't open without it) and turn on per-share view analytics (you see who opened it and when, anonymized to first-time / repeat).

Useful when posting nightly results to a channel where stakeholders don't have TestDossier accounts — or sending a customer a self-contained "what we tested for your release" page.

Upload a logo, pick a brand color, and set a display name — every export the app produces (HTML evidence, branded PDF, public share pages) carries them. Open from sidebar Tools → Branding. Logo lives in R2 (5MB cap, PNG/SVG/JPEG). Color drives the accent in headers and result chips on exported pages. Display name shows on share pages instead of the bare email.

Workspace-scoped: a workspace owner sets the branding once and every member's exports inherit it, so customer-facing reports look consistent regardless of who ran the test. Personal Pro users brand only their own exports.

Every time you click Log snapshot, a small dialog asks for the execution context — Build / Version, Environment, Browser, OS, optional Notes — and TestDossier freezes a complete record of the test case at that moment with that context attached. Industry pattern (TestRail / Xray / Zephyr): these belong on the per-execution record, not the case definition. Pre-fills smartly from the last snapshot for this case → last snapshot in this project → your most-recent submitted values. Press Enter to log; Escape to cancel.

Open Snapshots from the project menu or the sidebar to browse, filter, and compare them. Each row chips its captured Build + Environment so you can scan "ran against build X on env Y" without expanding.

• Filter: by project, result (PASS / FAIL / etc.), text search, plus a diff-aware filter — All snapshots / Changed only / Regressed only — so you can triage a noisy timeline in one click. The active filters persist across modal opens.
• Stability sparkline: when scoped to a single test case (Versions view), a 30-dot sparkline above the list shows the recent pass/fail/regression pattern. Each dot is one snapshot, oldest left to newest right; regressions (PASS → not-PASS at overall) carry a red ring.
• Inline diff chips: rows whose snapshot diverged from the previous one carry chips spelling out what shifted — FAIL → PASS, 2 steps regressed, 2 prose edits, +1 screenshot, etc. Stops at 3 chips per row with a "+N more" overflow on narrow widths; the diff viewer carries the full breakdown.
• Restore: replace the current test case with a prior snapshot — useful when you've accidentally edited away something important. The button only appears when the snapshot is a prior version of the active test case. Restoring shows a 10-second Undo toast with one-click revert; the operation is no longer destructive without a safety net.
• Clone: opens the snapshot as a new tab so you can edit and re-execute it without losing the original record.

Three distinct compare actions. History rows now carry up to three buttons, each answering a different question:

• Diff vs now — only on rows that are a prior version of the active test case. Opens a side-by-side diff with the snapshot on the left and your live edits on the right. "What have I changed since logging this?"
• View changes — on rows whose diff_summary has at least one change. Opens the structured diff between this snapshot and the run that came before it (the row's own previous run). No live tab involved. "What changed in this run, on its own terms?"
• Compare 2 selected — bulk action, enabled when exactly two rows are ticked via the row checkboxes. Opens the older snapshot on the left, newer on the right. "What changed between then and now, ignoring everything between?"

The diff viewer. Two evidence-aware sections, clearly labelled so the wrong verdict line never pairs with the wrong comparison:

• What changed in this run (Section A) — frozen at log time. Verdict line, structured chips (regressed / improved / prose / screenshots), per-step drill-down, and a lazy-loaded line-by-line text diff against the previous run.
• What's different from your current edits (Section B) — only in the run-vs-active flow. Stats line plus the line-by-line text diff against the live tab.
• Copy summary button in the modal header — produces a Slack/Jira-friendly plain-text digest of the chips, ready to paste into a ticket comment.

Diff fidelity details. A few invariants worth knowing if you rely on the chips:

• Steps match by id, not position — reordering steps doesn't show as remove+add.
• Diff base skips near-duplicate prior runs — parallel CI shards or retried jobs ingesting within 30 seconds of each other don't get picked as the comparison anchor; the engine prefers the most recent run with a decided overall result.

Audit-grade event log. Alongside the snapshots, the Snapshots modal also shows a chronological feed of audit-relevant actions — step result changes (per-step + bulk), overall-result overrides, defect notes added or cleared, image add / remove, custom column removal, step add / duplicate / remove, and snapshot logged / restored. The lens is "would a reviewer want to know this if a result is later disputed?" — content edits aren't logged (they'd be too noisy and the snapshot already freezes the state); structural changes and result transitions are.

Compare two blobs side-by-side without leaving the app: text, code, JSON (with key-order normalization), CSV (row-aligned), log files (timestamp-stripped), PDFs (text extraction), or images (pixel-level overlay). Open from sidebar Tools → Diff.

• Inputs: paste into either pane, drop a file (text, image, PDF), or use ⌘V on a screenshot. Both panes auto-detect kind — JSON / CSV / log / text / PDF / image — independently. Mixed kinds (e.g. text vs image) refuse to diff with a clear message.
• View modes: Side-by-side for line-by-line scanning, Unified for patch-style review. Word-level highlights inside changed lines so you can see exactly which token shifted.
• JSON smart-mode: on by default — {a:1, b:2} and {b:2, a:1} render as identical. Turn off when key order matters (e.g. ordered API responses).
• Image diff: overlays both images, highlights changed pixels with a configurable tolerance. Shows total pixel-changed % and a "size mismatch" warning when the dimensions differ.
• Save & Share: creates a permalink that anyone can open. Inputs ≤10 MB each (counts toward your Pro storage). Optional password + expiry. Saved diffs replay on the share page using the same engine.
• Tab restore: closing the panel keeps your inputs in place. Reopening picks up where you left off — no lost work mid-investigation.

The same engine powers Compare in History (snapshot vs current test case) and the read-only viewer behind shared diff links.

A workspace is a shared container — projects, test cases, history, plans, branding — visible to every member you invite. Personal mode is private to you; switching into a workspace puts you in shared context where teammates see your edits live and you see theirs.

• Create: Account menu → Workspaces → Create team workspace. First seat is included with Pro; additional seats are $15 / month each, billed via the same Lemon Squeezy subscription.
• Invite: from workspace settings, paste an email and pick a role (owner / member). Owners can manage members + billing + branding; members can edit shared content but can't add/remove people.
• Switch context: the workspace pill in the top bar is your current scope. Click ← Switch to Personal to leave the shared space; clicking a workspace name in the account menu switches into it. The pill is color-coded so you always know which scope you're editing.
• What's shared: projects, tabs, test runs, history, plans, branding, comments, mentions, presence — anything created while in workspace context. Local items in your personal scope stay personal.
• Membership lifecycle: leave any time from Account → Workspaces → Leave. Owners can step down (if at least one other owner exists) or remove members; removed members lose access immediately but their authored content stays. Workspaces can be archived (data preserved, no further edits) or fully deleted with a typed-name confirmation.

The features tagged (Workspace) below — real-time presence, activity feed, share-as-report, project insights — only activate inside a workspace context. In personal mode they're invisible.

By default, tabs and closed test cases live in your browser's IndexedDB — one device, one browser profile. This storage is per-origin, so different URLs (or incognito windows) keep separate buckets and don't cross over. If you sign in, tabs and snapshots also sync to your account so you can pick them up on another device. In a team workspace, that account-synced data is visible to everyone on the team.

If you're signed in to Pro, your tabs, snapshots, and test cases live on your account, not this device. Sign out ends the session and clears the local cache so the next person on this browser starts fresh. Sign back in on any device to see your synced data again. Use Sign out and forget this device on a shared machine when you also want to clear device preferences (theme, focus mode, dismissed banners).

Even with cloud sync, keep periodic local backups. Use Download Backup on each tab (or All Tabs ZIP from the output panel) to get a portable file you can restore later — handy for archival or moving work across accounts/workspaces.

Also: don't paste real passwords into the Test Data field. Use references like "password in 1Password vault X" instead.

Two screenshots with the same name collide in Jira (only one renders). The tool warns you when duplicates exist and the filename input turns red. Rename them to unique values.

With compression, typical test cases are well under browser storage limits. If you're accumulating hundreds of full-resolution screenshots in one tab, IndexedDB may refuse to save. The save indicator turns red when that happens. Export and archive in that case.

The raw Jira wiki syntax (pipes, dashes, {color} tags) reads messy. Switch to the Preview tab to see what it'll actually look like when rendered in Jira — that's the tab to judge output by.

If you closed it accidentally, open Test Cases — every test case in the project is listed there. Closed tabs (any with content that you closed) have a Restore button. Click it to bring the tab back.

Yes. Every cast and recast is preserved as its own row — the active verdict is the latest, but the prior ones stay in the share's history. In Manage shares → analytics, any reviewer who's flipped their vote shows a Show N prior casts link that reveals them inline, with the timestamp each one was replaced. Useful for answering "when did the PM approve this?" and for spotting reviewers who oscillated.

When creating a share, tick Require verified sign-off. Reviewers then confirm a one-time code emailed to the address they enter before their verdict counts — turning a self-asserted email into a proven one. They still need no account; the only thing emailed to them is the code (you distribute the link yourself, as always). Each signature records an intent (Author / Reviewer / QA Lead / Witness) and an optional note, and is append-only. Optionally list authorized signers (emails) to restrict who may sign at all; leave it blank to let anyone with the link sign (still email-verified). Comments stay open regardless — only the formal verdict is gated. In Manage shares → analytics each signed verdict shows a ✓ Signed · <role> pill. Reviewers can change the email they sign with — switching it just requires requesting a fresh code.

Two ways. One-off: use the Share button to publish a tab or snapshot as a read-only link — no account needed for the viewer. The link works in any browser; you can revoke at any time from the Share modal. Ongoing team work: create a team workspace from the Account modal, invite members by email, and projects, tabs, and snapshots created in the workspace are visible to everyone on the team. See "How does a team workspace work?" below.

Pro share options: shared links can be password-protected (the viewer must enter the password before the page loads — no preview, no SEO crawl) and carry per-share view analytics (you see how many times the link was opened, when, and a coarse first-time vs repeat split — emails are not collected). Both toggle from the Share modal. Useful for sending sensitive evidence to customers or auditors where you want both confidentiality and proof of access.

A workspace is a shared container for projects, tabs, and snapshots. Any member can create, edit, or log against workspace projects; the Snapshots list shows a "by you" / "by alice@…" chip so you know which teammate logged each one. Owners can invite/remove members, change roles, and manage billing ($15 per active seat per month, free while you're the only member). Switching context (workspace ↔ Personal) happens via the banner at the top — your personal tabs stay private to you regardless.

Not in real time. Workspace tabs use last-write-wins with a stale-check: if two people edit the same tab and one saves stale data, the second save returns a conflict and you can refresh. For a team, agree on who's editing what, or use separate tabs.

Yes for personal use — once the page is loaded, evidence capture and exports run entirely in your browser. Cloud sync, workspace access, and shares need network.

Yes, IndexedDB persists across updates. It only clears if you explicitly clear site data, use "forget this website," or switch browsers/profiles. Keep a periodic JSON export as backup anyway — storage loss from browser bugs is rare but not zero.

Not currently. Direct API integration would need your TestRail/PractiTest credentials stored somewhere — the CSV import route keeps them in the target tool. The data flows through a file artifact you can inspect before importing, which is also useful for review/audit.

No — you can use the entire capture/export workflow without signing in. Your data stays in your browser. Sign in (free, magic-link) if you want cross-device sync, cloud history, public share links, or to join a team workspace. Pro adds higher limits; team workspaces are billed per seat.

TestDossier runs on Cloudflare (Pages, D1, R2). If you're not signed in, no data leaves your browser. Once signed in, tabs/runs/screenshots you choose to sync are stored in your account; team-workspace data is visible to that workspace's members. You can export and delete your account from the Account modal at any time.

If you cancel Pro, your synced cloud data (cases, runs, screenshots) is kept for a 30-day grace period — re-subscribe to keep full access, or download a complete backup (cases and evidence, re-importable) — after which it may be deleted to free storage. Local browser data is never touched, and deleting your account erases everything immediately. (See Terms §6.)