Reference manual
Running BugSnap AI, end to end
BugSnap AI explores a real web application the way a curious tester would — clicking, typing, and navigating with no pre-written script — then turns what it learns into concrete test hypotheses, runs them for real, and surfaces only the defects it can independently reproduce. This manual covers every screen a customer actually uses, in the order you'll meet them.
Watch first (6 min)
A narrated walkthrough of how BugSnap AI explores, generates test cases, and reports reproduced bugs. Prefer reading? Skip straight to Getting started below.
▶Watch: How BugSnap AI worksOpens in a new tab — narrated, 6 minutes01 · Start here
Getting started
From signup to your first autonomous run, in five steps. Nothing here needs engineering help — the wizard collects everything BugSnap needs.
- 1Create your accountSign up with your work email and a password. A verification email arrives immediately — click through it to unlock your one-time 100-credit starter grant. Until then, an amber banner in the sidebar reminds you to verify.
- 2Name your workspaceA workspace groups one or more applications, one team, and one shared credit balance. Most customers only ever need one.
- 3Point it at your applicationGive the application a name, its base URL, and the environment you're testing — STAGING QA UAT DEV, or PRODUCTION. Choosing Production requires an explicit written acknowledgement — BugSnap will click, type, and submit forms on the live site your real customers use.
- 4Save a test loginIf your app requires sign-in, give BugSnap a real, dedicated test account (role, username, password). Exploration uses this exact credential for any login field it finds — it never invents one unless nothing is configured.
- 5Review scope & safety, then launchConfirm which real-world actions are in bounds (see Safety policy), then click Start autonomous exploration from the application page. BugSnap opens a real headless browser and starts mapping your app immediately.
Every field from onboarding — environment, credentials, allowed domains, safety toggles — stays fully editable afterward from the application page. Nothing is locked in at setup.
01 · Start here
Workspaces
A workspace is your team's home base — its own applications, members, and a credit balance shared across everything you personally own.
Switching workspaces
If you belong to more than one workspace, click the workspace name at the top of the sidebar to open the switcher. Selecting another workspace you're already a member of moves your session there immediately — no reload needed.
Your credit pool is shared, not per-workspace
Every workspace you personally own draws from the same credit balance. Spend credits running tests under one workspace, and every sibling workspace you own shows the identical, up-to-date number. This is deliberate — the one-time starter grant is tied to you as a person, not to how many workspaces you create.
How many workspaces can I create?
Your plan sets a real cap on owned workspaces:
| Plan | Workspace limit |
|---|---|
| No plan / Starter | 1 |
| Growth | 5 |
| Pro / Enterprise | Unlimited |
Reached your limit? Delete an existing workspace you no longer need, or upgrade — both routes are on the Workspace tab in Settings.
Deleting a workspace
From Settings → Workspace, workspace owners find a Danger Zone with a real delete action. It permanently removes every application, run, finding, and credential inside it — there's no undo. If the workspace has an active paid subscription, cancel that first from the Billing tab; BugSnap won't silently orphan a bill you're still paying.
02 · Set up testing
Applications
Everything BugSnap does — exploring, planning, executing, judging — happens against one application record at a time.
Editing application details
Typo the URL during onboarding, or need to rename it? Open the application and click Edit next to its name — name, base URL, and description are all editable in place, with the change saved immediately.
Allowed domains
By default, exploration and test execution stay within your application's own URL. If a real user flow legitimately crosses subdomains — checkout on pay.example.com, say — add those extra hosts to Allowed domains so navigation there isn't blocked mid-run.
How many applications can I add?
| Plan | Application limit |
|---|---|
| No plan / Starter | 1 |
| Growth | 5 |
| Pro / Enterprise | Unlimited |
At your cap, the Danger Zone on an existing application's page lets you delete it to free up a slot — this also removes its runs, findings, and credentials for good.
02 · Set up testing
Test credentials
A real, dedicated login BugSnap can use — never your own personal account, never a real customer's.
Adding one
On the application page, the Test credentials card holds every saved login, each with a role name (e.g. "Standard user", "Admin"), a username, and a status of ACTIVE or DISABLED. When exploration meets a login form, it uses the role that best matches the page — defaulting to the first if it's ambiguous.
Editing a credential
Click Edit beside any saved credential to change its role name or username. The password field is always left blank when you open it — BugSnap never re-displays a saved secret — leave it blank to keep the current password, or type a new one to rotate it.
Secrets are encrypted at rest (AES-256-GCM) and never appear in any API response, log, or export — only the role and username do.
02 · Set up testing
Safety policy & scope
Real, enforced toggles — not a disclaimer — that bound what an autonomous run is allowed to attempt.
| Toggle | What it controls |
|---|---|
| Allow form submission | Filling and submitting forms, including checkout and signup flows. |
| Allow account creation | Creating new test accounts during exploration. |
| Block destructive actions | Account deletion, data wipes, irreversible admin actions. |
| Block outbound email/SMS | Prevents real notifications from reaching real addresses. |
| Allow payment flows (test mode) | Only proceeds when a real test payment provider is detected. |
Each toggle reads honestly either way it's set — a "Block" toggle that's on shows Blocked, never a confusing "Allowed."
03 · Run & review
Autonomous exploration
No pre-written script. BugSnap looks at the real, current page and decides — one action at a time — what a curious tester would try next.
Starting a run
From the application page, click Start autonomous exploration. A real headless browser opens your base URL and begins deciding actions immediately; you land on the run page and watch steps append in real time.
What it prioritizes
- Core business workflows — login, checkout, account creation, settings
- Data-changing operations — anything that creates, updates, or deletes something real
- Role-sensitive areas — admin panels, permission-gated pages
- Complex, multi-step forms
- Plain navigation to pages not yet visited
Reading a run
Each run page shows, for real:
| Field | Meaning |
|---|---|
| Credits | Consumed / reserved for this run — settles the instant the run ends. |
| Workflows explored | Distinct, named business flows BugSnap recognized (e.g. "login", "add_to_cart"). |
| Steps | Every real action attempted, in order, with its real selector and outcome. |
| Observations | Real URLs, titles, and console errors captured along the way. |
A run stops on purpose — it exhausted its step budget, the AI judged nothing new was left to explore, or it hit a real safety boundary. A single stumbled AI decision no longer ends a run outright; BugSnap retries from the same state before giving up.
03 · Run & review
Test plans
This is where exploration's map becomes real, targeted test cases — the part built to catch what a happy-path click-through never would.
Generating a plan
Click Generate test plan on the application page once at least one exploration run has completed. BugSnap reviews every workflow it's learned — accumulated across every run to date, not just the latest one — and proposes 1–3 hypotheses per workflow, each grounded only in elements it has genuinely seen.
Categories you'll see
A real example, generated from an actual login workflow:
// DUPLICATE_ACTION "Verify that rapidly submitting the Login form twice does not create conflicting authentication state or duplicate requests that leave the user on an inconsistent page." risk 0.32 credits 10
Running a hypothesis
Click Run this test on any pending hypothesis. BugSnap executes its exact steps in a fresh browser, then has a separate AI pass judge the real outcome against what the hypothesis expected — never assuming success just because the actions completed.
03 · Run & review
Findings & evidence
Every finding is honest about how sure BugSnap is — and shows its work.
Classifications
| Classification | What happened |
|---|---|
| CONFIRMED | Failed twice, independently, in two fresh browser sessions. |
| SUSPICIOUS | Failed once; independent reproduction didn't repeat it. |
| PROBABLE | Failed once; reproduction was skipped (budget or cost limits). |
| DUPLICATE | Matches a finding already on file for this application. |
A genuine pass vs. an inconclusive result
"No defect found" only ever means the AI judge actually compared the real outcome to the expectation and confirmed it held. If the judgment call itself fails for any reason, BugSnap says so plainly — it never reuses the reassuring "no defect found" message for a result it doesn't actually have.
Evidence
Screenshots are captured the moment something goes wrong, then shown as real, clickable images on the finding — click any thumbnail to open it full size. If several consecutive screenshots look identical, that's real signal too: the page genuinely never changed while the failure kept recurring.
03 · Run & review
Reporting a bug manually
Found something yourself, mid-demo or during your own click-through? File it directly — no exploration run required.
On the application page, open Report a bug and fill in a title, severity, what you expected, what actually happened, and the steps that reproduce it. It appears on the Findings page immediately, alongside everything the AI pipeline discovers on its own — the two paths coexist without interfering with each other.
03 · Run & review
Regression tracking
BugSnap's memory for “didn't we already fix this?”
Any CONFIRMED finding can become a regression check — click Create regression check from its detail page once you believe it's fixed. From then on, that exact workflow is re-run automatically whenever a fresh exploration touches it, and BugSnap flags it immediately if the same failure comes back.
03 · Run & review
Scheduled runs
PRO PLANSet up recurring autonomous exploration — daily at a chosen UTC hour, or weekly — from the application page's Scheduled runs card. Each scheduled fire re-checks real plan access and real credit capacity at the moment it runs, not just when you set it up, and shows its next and last run time so you always know where it stands.
04 · Account
Plans, credits & billing
Credits meter real AI and browser usage — a longer test costs more than a two-click one, transparently.
- 2,000 credits/mo
- 1 application
- 1 workspace
- 8,000 credits/mo
- 5 applications
- 5 workspaces
- 22,000 credits/mo
- Unlimited applications
- Unlimited workspaces
- Scheduled runs
Yearly billing runs roughly two months free versus paying monthly. Changing or cancelling a plan is self-serve from Settings → Billing; a cancellation keeps your access until the current period ends.
04 · Account
Team & roles
Invite teammates from Settings → Members — they need an existing BugSnap account first. Every role below is enforced on the server, not just hidden in the UI.
04 · Account
Integrations
Send a confirmed finding straight to where your team already tracks work.
Connect GitHub, Linear, Jira, or Slack from Integrations, then use Send to integration on any finding's detail page. BugSnap includes the real reproduction steps and evidence in the outgoing issue or message — nothing needs re-typing.