Welcome to GoQA

GoQA turns plain-language requirements, live URLs, screenshots, and OpenAPI specs into comprehensive BDD test suites — and crawls any web application to surface accessibility, performance, SEO, and security defects in minutes. This documentation covers every feature available in v0.4.0.

Quick start (3 steps)

Get your first test cases in under two minutes — no setup, no CLI, no configuration file required.

1. Open the Test Cases workbench at /test-cases. Paste acceptance criteria, a URL, a screenshot, or an OpenAPI spec into the input panel.
2. Click a test-type tile (e.g. Functional, E2E, Security) to generate BDD scenarios for that category.
3. Mark Pass / Fail on each case, then export as JSON, Excel, or Gherkin — or open the set in the Test Repository preview (not saved).

Account creation

Visit /signup to create a free account with email and password, or sign in with Google or Microsoft where those providers are enabled. Confirm your email address from the link GoQA sends before signing in; if it never arrived or has expired, try to log in and choose Resend confirmation email. New accounts are on the Starter plan.

Forgot your password? Use Forgot password? on /login (or /forgot-password). GoQA emails a link to set a new password; open it in the same browser you requested it from. Signed in, you can change your password (or set one, if you sign in with Google or Microsoft) from Settings → Password.

The Dashboard shows a short onboarding tour until you finish or skip it. See Onboarding tour.

Plan overview

Full pricing at /pricing. Summary:

• Starter (free) — limited access to every released testing workflow: 10 AI test generations and 5 website crawls a month (5 pages per website each month), up to 200 cases/request, scheduled audits within the same crawl limits, shared reports and badges, and JSON, Excel and .feature export, single user.
• Enterprise (custom pricing) — unlimited generations and crawls of up to 50 pages. Use Talk to sales on /pricing.
• Complete audits — run by the GoQA team and requested by email to team@goqa.ai.
• AI Assurance — limited preview, not sold at checkout. Starter includes limited self-serve API and agent-trace testing, switched on in stages (see Starter self-serve); GoQA enables anything more per workspace when you request access. See AI Assurance.

Accounts still on the retired Pro plan keep their subscription and can manage it from /pricing.

Your current plan, monthly usage, and upgrade CTA are shown at the top of the Dashboard. The usage bar turns amber at 80% of your monthly generation limit and red at 95%.

Test Case Generation — overview

The Test cases workbench is the primary surface for turning a specification into BDD test scenarios (test cases, not automation code). It supports four input methods, 18 test-type categories, AI refinement of single cases, and a coverage score per result.

Input methods

Switch between tabs in the input panel to choose your source:

• Acceptance criteria — paste plain text or Gherkin (Given / When / Then). The model reads it directly and maps each criterion to scenarios.
• From URL — give a public URL. Playwright visits it server-side, extracts headings, lists, and form fields, then feeds them to the generator.
• Screenshot upload — drop a PNG / JPG / WebP. OpenAI Vision extracts on-screen criteria; you can append free-text notes to guide generation.
• OpenAPI spec — enter the URL of an OpenAPI 3 JSON spec. GoQA lists each endpoint's method, path, summary, required parameters, documented response codes and whether it requires auth, as editable text that the generator uses. See OpenAPI specs.

Import a Chrome recording: record a flow in Chrome DevTools → Recorder, choose Export → JSON, then Import Chrome recording in Saved Test Cases. GoQA saves it as a test case whose steps replay without the AI (see Run a case in a browser), using the recording's accessible selectors (names, roles and text), and the AI heals a step when the page changes. Steps found only by CSS or XPath, clicks that look like they delete data or spend money, and pages on other sites are left for the AI to plan. A password typed in the recording is never stored. A case can have up to 15 steps.

Import CSV or Excel: bring cases from TestRail, Qase or a spreadsheet. The file needs a header row; GoQA reads Title, Steps (one per line; numbering is removed), Expected, Preconditions and Section (or Suite, Category), and leaves every other column out. TestRail's "separated steps" export works too: a row without a title adds its step to the case above. GoQA's own Excel export imports back as it is. Up to 200 cases per file and 15 steps per case; the file stays under 1 MB.

Test data (data-driven runs): on a saved case, Add test data takes CSV (or rows pasted from a spreadsheet): a header row of column names, then up to 10 rows. Write <column> in a step, as in a Gherkin Scenario Outline, and each row runs the case once with its values. Run in browser runs every row or the one you choose; Run all and scheduled runs run every row, and each row counts as one case run (one crawl credit on Free and Starter). Rows are planned by the AI each time and never use recorded steps. Columns named like passwords or secrets are refused. Run history and its flaky-case summary show each row on its own line, and the .feature export writes the case as a Scenario Outline with an Examples table.

Test types & output formats

Click any of the 18 category tiles to generate cases for that type. One type generates at a time; the other tiles are disabled until it finishes.

• Categories: Functional, E2E, Smoke, Regression, Accessibility, Visual, Performance, Security, API, Cross-Browser, Mobile, Forms, Network, Negative, Load, Usability, Compatibility, Localization.
• Output structure: each case has a title, category, optional preconditions, Given/When/Then steps and an expected outcome.
• Filter panel: hide test types you do not need using the “Filter test types” button to focus results.
• Case limits: anonymous: 50/request; free account: 200; Enterprise: 10,000.

AI Test Coverage Score

Each result panel shows a 0–100 score for the cases in that panel: 70 points for how many of the 18 test types its cases cover, and 10 points each for a happy path, an error path and an edge case (recognised from keywords in the case titles). Click the score to see the types the panel does not cover. Generating another type adds a separate panel with its own score.

The score is calculated in your browser; it is not saved.

Refine with AI

Once test cases are generated, click “Refine with AI” on any individual test case to open an inline editing prompt. Type natural-language instructions such as:

• “make this stricter” — tightens preconditions and assertions.
• “add mobile viewport” — prepends a viewport-resize step.
• “add negative test” — rewrites the case as a failure scenario.

The refined case replaces the original in the panel. Refine always returns one test case, not automation code, and the change is not saved to your stored test case set.

Run a case in a browser

Signed in, open a saved set under Saved Test Cases. Each case with steps has a Site field (filled with the set's URL when it has one) and a Run in browser button. GoQA opens the site in Chromium and performs the steps one by one: for each step, AI reads the page and picks one action (open a page, click, type, choose an option, press Enter/Tab/Escape, or check that text, the address or the title is there).

• Each step shows Pass, Fail, Blocked or Not run, what GoQA did, the reason when it did not pass, and a screenshot.
• The run stops at the first step that fails or is blocked. Steps that need things GoQA does not have (a real account, an email, a payment) are marked not run; a case where nothing could be checked is not counted as a pass.
• GoQA stays on the site's own address, never types into password or file fields, and does not click buttons that look like they delete data or spend money (delete, pay, buy, checkout, place order, …).
• The last run of each case is saved with the set and shown when you open it; each run is also recorded in your account's test runs. Screenshot links last an hour and are renewed when you reopen the set.
• Next to the Site field, a Browser menu runs the case in Firefox instead of Chromium; the result line says when a run used Firefox. If the start address redirects to another host (for example to www.), the run continues on that host.
• Run all N cases at the top of an open set runs every case that has steps, one after another, each against its own Site. The line under it counts passes and failures as they finish. Stop after this case ends the batch once the running case finishes, and the batch also stops if your free crawl credits run out.
• Recorded steps: the first run of a case in which every step passes is recorded. Later runs against the same site replay those actions without the AI, which is faster and gives the same result each time. If the page changed and a recorded click, typing or page opening no longer works, the AI finds that step again and it is marked Healed. Check healed steps, then choose Keep the healed steps to update the recording; until you do, the recording stays as it was. A recorded check that fails is never healed: it fails the case. Editing a case's steps or running it against another site uses the AI again, and Forget recorded steps drops the recording.
• Run history under the cases lists this set's browser runs: when, which case, the result, how long it took and the first step that did not pass. Its Results by case summary (pass rate, flaky or failing, where a case fails most) leaves out runs from before you last edited a case's steps by hand, since those runs used other steps, and says how many it left out.
• A run uses one crawl credit per case on the Free and Starter plans, and up to 20 runs per hour. The credit is used once the browser has opened, so a run that could not start costs nothing.
• Write cases by hand: in a saved set, Edit changes a case's title, steps, expected result and preconditions, and + Add a case adds one at the end. Write the steps in plain English, one per line (at most 15), for example "Click Create account" or "Check that Welcome is shown": Run in browser turns each line into one action on the page. Changing the steps forgets the case's recorded steps and its Pass/Fail mark, and the case shows when its steps were edited, since earlier runs used other steps. Cases are not removed or reordered, because run history and schedules refer to each case by its number.
• Run on a schedule (under Run history) runs the set's cases with steps daily, weekly or monthly against one site, in the browser you choose, starting within 10 minutes of saving. Up to 10 cases run per scheduled run, one after another, as Run all does, with the same recorded steps and credits. Scheduled runs appear in Run history marked scheduled; the panel shows the next run and how the last one went, and your notification channels (Settings → Notifications) hear about failures. Pause or remove a schedule at any time. An account can schedule up to 10 sets.

Exporting results

In a saved set, Export Playwright downloads a Playwright Test file (.spec.ts). Each case with recorded steps becomes a test that repeats the recorded run's actions (open the page, click, type, choose, press, check text, address or title) and acts on the live site as that run did. Cases without a recording are test.fixme with their steps as comments, so they show as not implemented, never as passing.

Three export formats, no proprietary runtime required:

• JSON — full row including category, steps, expected outcome, execution status, and notes.
• Excel (.xlsx) — one sheet with a column per field, which you can map when importing into another test management tool.
• .feature (Cucumber / Gherkin) — one Scenario block per case, ready for playwright-bdd / cucumber-js / any BDD runner.

Mark Pass / Fail / Blocked / Skipped on each case before exporting to include execution status in the output. Failed and Blocked cases expose a notes textarea for defect links or root-cause comments.

AI Website Auditor — run an audit

Open /ai-testing, type or paste any URL — bare domains like example.com are auto-upgraded to https:// — and click Run AI Test. No sign-up is needed for a first audit. You can also kick off an audit straight from the homepage: enter a URL in the top launcher and we'll redirect to /ai-testing?url=… with the crawl already running.

The crawler streams page discoveries live; heavier panes (screenshots, security, a11y, performance, SEO, forms, network) render once the crawl completes.

• Live crawl streaming — Playwright starts at your URL, follows links on the same host up to your plan's page limit, and streams each page as it is visited.
• Screenshots — one viewport screenshot per page.
• Accessibility — automated WCAG rules — axe-core runs every rule tagged wcag2a, wcag2aa, wcag2aaa, wcag21a, wcag21aa, wcag21aaa, wcag22a, wcag22aa, plus section508, EN-301-549, ACT, best-practice, and experimental. Every violation surfaces its impact (critical / serious / moderate / minor), conformance level (A / AA / AAA), the exact success criteria (e.g. 1.4.3 Contrast, 2.4.7 Focus Visible, 4.1.2 Name·Role·Value), the failing DOM target with HTML snippet and axe's failure summary, and a link to the official rule reference. Automated rules cover only part of WCAG; see the WCAG section below.
• Performance — navigation and paint timing per page, Largest Contentful Paint and layout shift when the browser reports them, and a Lighthouse run on the start URL when Lighthouse can launch on the server.
• Browser — crawls run in Chromium by default. Choose Firefox in the Browser menu next to the compare option to check the site in Gecko as well. A Firefox crawl runs every check above except Lighthouse (Chrome only); Firefox reports no Largest Contentful Paint, and screenshots are not compared with your baselines, which are Chromium screenshots. WebKit (Safari) is not offered.
• SEO — title, meta description, H1 count, canonical link and Open Graph image per page.
• Broken links — up to 25 links per crawled page on public hosts are requested; errors and 4xx/5xx responses are flagged.
• Security scan — OWASP-aligned non-destructive probes: security headers, weak cookies, reflected-XSS markers, SQL-injection smells, information-disclosure paths. Each finding includes severity, evidence, recommendation, and a curl -i reproduction command.
• Forms — an inventory of each form's fields and which are required (forms are not submitted).
• Network log — captured requests and responses for all pages crawled.

WCAG accessibility — what the automated check covers

The accessibility check runs axe-core with the tags wcag2a, wcag2aa, wcag2aaa, wcag21a, wcag21aa, wcag21aaa, wcag22a, wcag22aa, section508, EN-301-549, ACT, best-practice and experimental. Each violation reports its WCAG success criteria (for example 1.4.3), conformance level, impact, the failing DOM nodes and a link to the rule reference. Rules axe could not decide are listed per page as needing manual review.

The Accessibility results (on the crawl page, in saved reports on the dashboard and in shared reports) start with a WCAG 2.2 conformance summary. Choose a level (A, AA or AAA, default AA) and it says whether any success criterion at that level fails on the pages checked. It then lists each affected criterion with its name, level, result (Fails, or Needs review when axe could not decide), the number of pages and the axe rules involved. Pages where the check could not run are counted separately, and best-practice rules outside WCAG are counted but not used for the verdict. With no failures it says so and that a manual review is still needed; it never reports a site as conformant.

Crawling as a signed-in user

Signed in to GoQA, open Crawl as a signed-in user under the address on AI Testing and paste the Cookie header of a session on your site: sign in there with a test account, open your browser's developer tools, pick any request to the site in the Network tab and copy its Cookie request header.

• The address must be https://. The cookies go to the crawl browser for that exact origin only (not subdomains or other sites) and are never saved, logged or shown again.
• Because the crawl acts as that account, it does not open links whose address looks like log out, sign out, delete, remove, cancel, unsubscribe, revoke or close account; the security scan checks headers, cookies and forms but sends no XSS or SQL-injection probes; recorded API calls are not repeated; and Lighthouse is skipped (it would score the signed-out page). The site's own page scripts still run as that account, as in a normal visit.
• If the start page redirects to another host (for example www.), the cookies do not go with it: start from the address the site redirects to.
• If the start page lands on a sign-in page, the results say the session may have expired.
• Screenshots and results of signed-in pages are saved in your report like any other crawl, so avoid accounts with real personal data.
• Scheduled audits and the CI API do not take cookies.

Multi-environment compare mode

In AI Testing, enable Compare Mode to audit two URLs side-by-side — for example, staging.example.com versus example.com. The diff view categorises every finding as:

• New — issues present on the second URL but not the first (regressions).
• Fixed — issues on the first URL that no longer appear on the second (resolved).
• Unchanged — issues present on both (pre-existing).

Compare Mode runs accessibility, security, and broken-link checks on both targets. Performance and screenshot checks are run independently per URL.

Scheduled audits

Create a schedule at Settings → Scheduled Audits with a URL, a frequency (daily, weekly or monthly) and, optionally, a Slack, Discord, Teams or Google Chat webhook. Schedule only websites you own or have permission to test.

• When it runs: the first run is due one period after you create the schedule. A run starts after its due time, when GoQA's scheduler next runs; there is no guaranteed start time. A missed slot is skipped, not made up.
• Your plan's limits: a scheduled run is an audit on your account. It uses your plan's page cap and, on Starter, the monthly per-website page quota and crawl credits, with the same private-address checks as a manual audit. When a limit is reached, the run is skipped.
• Results: a completed run saves its result to your Dashboard like a manual audit. Settings → Scheduled Audits shows each schedule's last run: completed, skipped or failed, with the reason.
• Notifications: the schedule's webhook is notified when a run completes, is skipped or fails. Your account webhooks in Settings follow their “notify on complete” and “notify on fail” switches.
• One audit at a time: scheduled audits for the same account run one after another. On Starter, scheduled audits and audits you start yourself share each website's monthly page quota: while one crawl of a website is running, a scheduled run of the same website waits and is retried later, so the quota is never used twice.
• Interruptions: an audit that is interrupted or fails before producing a result is retried, up to 3 attempts in total. If it never produces a result, its crawl credit is given back.
• Pausing, changing or deleting: a schedule that is paused, has its URL or frequency changed, or is deleted stops its unfinished audit: nothing more is crawled, saved or notified, and a crawl credit already taken for it is given back.

Shareable report URLs

In the Dashboard, open an audit and click Share. GoQA creates a secret token and a public link:

https://goqa.ai/report/[token]

Anyone with the link can open a summary of that audit without signing in: the site, the numbers of pages, security findings, accessibility issues and broken links, the first security findings, accessibility issues and broken links, and a few screenshots. Turning sharing off removes the token at once, and the link stops working. The Share button does not remember an existing link after the page reloads; sharing again creates a new link and the old one stops working.

Embeddable audit badge

A shared report page shows the badge and its embed code. The badge is an SVG served at:

https://goqa.ai/badge/[token]

• Red — the audit has a critical security finding.
• Amber — it has other security findings or broken links.
• Green — neither.
• Grey, “Not shared” — the link does not exist or is no longer shared.

The badge shows the date of the audit it belongs to. It does not follow later audits: a new audit needs its own share link and badge. Browsers and CDNs may cache it for up to an hour.

Screenshot baselines

In the screenshot panel of an audit, “Set as baseline” records that screenshot as the reference for its page URL in your account. Every later signed-in or scheduled audit that screenshots the same page compares it with the baseline pixel by pixel: the saved audit's Visual changes tab on the Dashboard shows the baseline, the new screenshot, the changed pixels in red and the percentage changed. A page counts as changed from 0.5% of its pixels. Setting a new baseline for a page replaces the old one.

AI Assurance — overview

AI Assurance runs readiness assessments for LLM applications, RAG apps, chatbots and AI agents. It produces risk findings and test evidence you can reproduce, and a release gate that turns them into a pass, block or needs-approval decision.

There are two workflows: LLM Testing and Agent Testing. Both start from a target you are authorized to test and follow the same six steps.

Availability: AI Assurance is in limited preview. Starter includes limited self-serve testing of APIs and agent traces, switched on in stages; GoQA enables anything more per workspace when you request access. See Pricing for availability, or request access by email. Each capability (URL runner, API targets, trace ingestion, the OpenAI judge) is switched on separately, so a workspace may have some channels and not others.

Starter self-serve

Starter self-serve, switched on in stages: test an OpenAI-compatible API you own and your agent's traces, with 20 runs and 500 traces a month, up to 25 prompts a run, 2 API and 2 trace targets, 2 active ingest keys, evidence kept 30 days and you as the only member. URL-only testing and the OpenAI judge are not included; complete audits are requested by email to team@goqa.ai.

GoQA switches Starter self-serve on in stages. When it is on for you, opening AI Assurance gives you one Starter workspace, and its dashboard shows this month's usage against each limit. It needs a confirmed email address.

Each API target still needs the same authorization as any other: verified ownership of its origin by a DNS TXT record or an HTTPS file, and a recorded authorization. The offline demo counts as a run but its sample-trace target does not use a trace-target slot. When a limit is reached, GoQA says which one and when the monthly counts reset (00:00 UTC on the first of the month); traces sent over the monthly limit are refused with HTTP 429 and a Retry-After header.

LLM Testing

LLM Testing assesses chatbots, RAG apps and LLM features through their visible interface (URL-only) or an OpenAI-compatible chat endpoint (API-connected). Built-in suites cover:

• Functional quality — correctness, relevance, completeness, instruction following and formatting.
• Groundedness — unsupported claims, context relevance and sufficiency, citation support, and stating uncertainty when evidence is insufficient.
• Security and guardrails — defensive prompt-injection and jailbreak resistance, system-prompt disclosure attempts and sensitive-data leakage checked with canary tokens. Probes are benign proxies, never harmful payloads.
• Robustness — paraphrases, ambiguity, typos, long context, consistency, and error, retry and streaming behavior.
• Configuration sensitivity (API only) — temperature, top_p, max tokens and seed sweeps with cost, token and latency comparisons.
• Policy packs — see Suites & policy packs.

Failures are named precisely — for example unsupported claim, incorrect answer, insufficient retrieval, citation mismatch, unsafe overconfidence, policy violation, format violation or regression — and never collapsed into a generic label.

Agent Testing

Agent Testing checks what an agent does, not only what it says. It has two modes:

• Black-box (URL-only) — assesses visible conversation behavior. GoQA does not infer hidden tool calls or internal planning in this mode.
• Trace mode — your server sends the agent's trajectory through the GoQA SDK. GoQA scores goal completion, tool selection, arguments and order, approvals and permission boundaries, loops, delegation depth, budgets, recovery after errors, and whether completion claims are backed by recorded tool results.

Trace detections describe measured mismatches between the trace and the agent's behavior — for example “Completion claim not supported by any successful tool result”. They never allege intent. Select up to 50 stored traces per evaluation on the Agent Testing page.

API & trace setup

Create a target in the target wizard. Choose how much evidence GoQA can collect. URL-only testing is not available yet, so connect an API or send traces.

1. URL-only (not available yet) — enter the https URL of the chat page and up to five extra origins it needs. Private, loopback and internal addresses are rejected, and URLs may not contain credentials.
2. API-connected — enter the OpenAI-compatible endpoint, path and model. An admin or owner stores the credential; it is encrypted (AES-256-GCM) and never shown again, not even in part.
3. SDK / trace-connected — create the trace target, then an admin or owner creates an ingest key on the target page. The key is shown once. See SDK, traces & retention.

Before any run, URL and API targets need verified ownership of every origin in their scope, then an authorization. On the target's Authorization tab an admin or owner proves control of each origin in one of two ways:

• DNS TXT record — publish goqa-verification=<token> as a TXT record at _goqa-challenge.<hostname>. It covers every origin on that exact hostname, but not subdomains.
• HTTPS verification file — serve the same line in /.well-known/goqa-verification.txt at the exact origin. Redirects are not followed, and it works only on the default port (443); for an origin on another port, use the DNS record.

A proof lasts at most 90 days after its last successful check, and an admin or owner can revoke it at any time. GoQA checks it again when a run starts and at least every 10 minutes while the run goes on; if the record or file is gone, the run stops before sending anything more and the verification is marked failed. Signed letters or contracts are not accepted as proof, because GoQA cannot check them: if the system belongs to someone else, its owner publishes the record or file. Reserved names such as .test or .invalid cannot be verified. See Security & authorization.

Selector mapping

For URL-only targets GoQA must know which elements on the page form the chat. On the target page, run detection: GoQA opens the page in an isolated browser, finds candidate elements without typing anything, and validates them.

Review the detected selectors, adjust any that are wrong, and save. Detection can only be applied when it finished cleanly and the selectors validated. If GoQA finds a login wall or CAPTCHA it stops: it never enters credentials, solves CAPTCHAs or bypasses access controls.

Suites & policy packs

Test plans are built only from approved, versioned templates in the GoQA AI Test Knowledge Base, reviewed by GoQA staff with a reviewer different from the author. GoQA matches templates to your target (channel, application kind, declared features such as retrieval or tools, domain and locale), ranks them and bounds the plan by your budget. Every case records the template version, evaluator and rationale it came from, and you can deselect cases before running. No free-form hostile prompts are generated.

Policy packs you can add to a target:

• Privacy, company policy, brand voice and accessibility
• Cautious language for finance, health, legal and HR

In Suites editors can keep reusable datasets, including a regression dataset built from confirmed findings.

Evaluators & OpenAI-as-judge

Each case names its evaluator and version. Deterministic evaluators check status, latency, JSON schemas, required and prohibited content, canary-token leaks, citation presence, tool-call contracts, response length and refusals; trace detectors check agent trajectories. Rubric-based cases use an LLM judge only when all of these hold: GoQA has enabled the judge for the workspace, a workspace owner has consented in AI Assurance settings, and the target's data classification is at or below the classification that owner allowed.

• The judge calls the OpenAI Responses API from GoQA's server with a strict JSON schema and store: false. It sees only redacted material: the case input, the output, and any supplied context or trace.
• Its answer is re-validated: fields and ranges are checked, and every evidence quote must appear word for word in the supplied material. Fabricated evidence is rejected.
• Low confidence, critical severity, a refusal, an incomplete or invalid answer, or disagreement with a second evaluator marks the result needs review for a person to decide.
• A pass on a high-severity, security, privacy, agent-behavior or policy-pack case always gets a second opinion, because judged output can contain text aimed at the judge.
• Judge calls count against the run's dollar budget, priced per model: the judge runs only when GoQA has a price for the exact judge model, and cached input is priced separately from new input. Before a run starts, GoQA projects the judge requests its selected cases need and refuses the run if its cost limit cannot cover them. Before each request, and before each retry, it reserves a conservative estimate of that request and refuses it if it does not fit; afterwards it charges the reported usage, or the full estimate when none was reported. A refused call produces an error result, never a silent pass. The run page shows judge tokens and cost by model. Cancelling a run aborts judge calls in flight.

Findings, reports & release gates

A run stores an immutable, redacted result for every case: input, output, evaluator and version, verdict and evidence. Failed cases become findings with severity, likelihood, confidence and remediation guidance.

• Review — reviewers, admins and owners mark findings confirmed, false positive, accepted risk or resolved. Decisions are kept permanently.
• Regression cases — an open or confirmed finding can be promoted to a draft regression case; a reviewer approves it before suites include it.
• Reports — executive and engineering views, exported as JSON, CSV or Markdown, or printed to PDF from the browser. Reports include the assessment disclaimer and, for URL-only runs, the URL-only limitation.

A release gate decides pass, block or needs approval:

Block wins over needs approval, which wins over pass, and every triggered condition is listed. A gate supports a release decision; it is not a certification.

URL-only testing

URL-only testing drives a real browser against your own web application and reports what a user could see: visible answers to bounded, defensive test prompts, refusal quality, disclosure behaviour, citations, error states and timing.

URL-only testing observes externally visible behavior. It cannot prove hidden prompts, temperature, retrieval documents, tool calls, guardrails, memory, or internal reasoning. Findings describe observable behavior and potential risks. Connect an API or trace source for deeper evidence.

Why an unverified URL is refused

• Sending test traffic to a site is only safe when the person asking controls it, so GoQA proves control itself rather than taking your word for it.
• An unverified origin cannot be authorized, and without an active authorization for the exact scope a run is refused before any request leaves the sandbox.
• The worker re-checks the proof before a run starts and again while it runs, so ownership that is revoked or expires stops the run in progress.
• Scopes are https only. Private, internal, loopback and reserved addresses are refused, so this can never be pointed at a network GoQA is not meant to reach.

Proving you control the site

Prove control of every origin in the scope. You can do this before the capability is switched on for your workspace — ownership and enablement are separate, and doing it first means nothing is waiting on you afterwards.

A verification lasts 90 days from its last successful check, and an admin or owner can revoke it at any time.

What bounds a run

• The browser runs in a locked-down container: every Linux capability dropped, a non-root user, a read-only root filesystem and a seccomp profile.
• Egress is default-deny. Only TCP 443 to public addresses is allowed; cloud metadata, private ranges, carrier-grade NAT, link-local addresses and UDP DNS are all refused.
• Every run carries a budget. By default 25 prompts, 1 at a time, at most 12 requests a minute and 15 minutes, and never more than 200 prompts or 4 at a time whatever is requested.
• Prompts are defensive and bounded. GoQA does not attempt to break, deface or exhaust your application, and stops when the budget is reached.
• An admin or owner authorizes a specific scope, and the authorization is tied to a fingerprint of it — widening the scope invalidates it.

Getting it enabled

URL-only testing is enabled per workspace, after a sandbox proof, verified ownership, an agreed pilot scope and time box, and an independent review. It is never switched on globally. Request it by email and say which origins you want tested.

An owner or admin can start and check an ownership challenge from Integrations at any time — it does not wait on the capability being switched on, and doing it first means nothing is pending afterwards.

Security & authorization boundaries

• Verified ownership, then authorization. A statement alone does not authorize testing. Every origin in the scope needs verified ownership (a DNS TXT record or an HTTPS file, as described in setup), and then an admin or owner confirms authorization for the exact scope shown, with an expiry of at most 366 days. The database refuses a URL or API run without both, and checks them again when a worker picks up the job and at every job heartbeat; workers also re-check the proofs live before sending anything and during the run. Changing the target's scope revokes the authorization.
• Roles. Viewers read; editors create targets and runs; reviewers review findings and approve gates; admins also authorize targets, manage credentials, ingest keys, gates and target data classification; owners also manage retention and consent to LLM judge processing.
• Tenant isolation. Every workspace's data is separated by row-level security and database constraints; references across workspaces are rejected.
• Bounded runs. Runs are capped on prompts, request rate, tokens, cost and duration, and can be cancelled at any time.
• Egress controls. Server requests go only to the authorized scope at a pinned, validated address and never follow redirects. URL-only tests run in an isolated browser. The URL runner is off by default; once released, it is offered only while a worker has recorded a passing network-sandbox check in the last 15 minutes, and only such a worker picks up URL jobs. Changes from the browser are accepted only from GoQA's configured web address; forwarded host headers are never trusted. Trace uploads are rate-limited by a limit shared across all of GoQA's servers, and are refused if that limit cannot be checked.
• Redaction. Secrets and personal data (API keys, tokens, emails, phone numbers, card numbers and more) are redacted before anything is stored, logged, exported or sent to the judge.

SDK, trace ingestion & retention

Send traces from your server — never from browser code — with the GoQA JavaScript trace SDK and an ingest key. Integrations has the SDK quick-start with your workspace's endpoint.

import { createGoqaTraceClient } from "./goqa-trace-sdk/client.js";

const goqa = createGoqaTraceClient({
  endpoint: "https://goqa.ai",
  ingestKey: process.env.GOQA_INGEST_KEY,
});
const trace = goqa.startTrace({ sessionId: "sess-42" });
const call = trace.toolCall({ name: "issue_refund", arguments: { orderId: "ORD-4471" } });
trace.toolResult({ callEventId: call, status: "ok", output: { id: "re_1" } });
trace.assistantMessage("I've refunded order ORD-4471.");
await trace.end();

• Endpoint: POST /api/ai-assurance/ingest/traces with the x-goqa-ingest-key header over HTTPS.
• Event types: user and assistant messages, LLM calls, retrievals, tool calls and results, agent steps, approval requests and decisions, delegations, errors and feedback.
• Limits: 1 MB per request and 2,000 events per trace. Validation is strict, and error messages list field paths only, never your data.
• The SDK validates locally, batches, retries safely with idempotency keys, and redacts by default before sending. GoQA redacts again before storing.
• Ingestion does not start an evaluation; choose traces on the Agent Testing page.

Retention. Completed, failed and cancelled runs and their evidence are deleted after the workspace retention period — 90 days by default, adjustable by the owner from 7 to 730 days in AI Assurance settings. The audit log is kept separately (400 days by default).

Limitations

URL-only limitation: URL-only testing observes externally visible behavior. It cannot prove hidden prompts, temperature, retrieval documents, tool calls, guardrails, memory, or internal reasoning. Findings describe observable behavior and potential risks. Connect an API or trace source for deeper evidence.

• API-connected tests do not see retrieval documents, tool calls or memory inside your application unless the API returns them.
• Trace mode sees only what your code reports. It cannot show uninstrumented tools, hidden prompts or memory stores, and it does not re-measure reported timings, tokens or costs.
• Trace detectors are English and pattern-based. They favor missing a problem over flagging one that isn't there, so a clean trace is not proof of correct behavior.
• LLM-judge verdicts are model judgements. Uncertain and critical ones go to human review, and all of them can be overridden by a reviewer.
• URL-only testing stops at login walls and CAPTCHAs.

Test Repository (preview) — suites

/test-repository is a preview of test management. It opens with sample suites. You can import a saved test case set from the Test Cases workbench (“Move to Repository”), create suites, add and delete cases, set each case's status by hand, filter by status, type or priority, and export to Excel.

Execution cycles (simulated)

The Cycles view runs a cycle template (for example Smoke or Full Regression) over the cases in the repository. GoQA does not execute your tests: each case that is still pending gets a random pass or fail result and a random duration, so the cycle log and its summary counts are a demonstration, not a measurement of your application. Cases you already marked keep their status.

Trends (sample data)

The Trends & Graphs view shows fixed sample numbers so you can see the layout. It is not calculated from your cycles or statuses, and GoQA does not compute flakiness percentages.

What is saved

Only generated test case sets (Test Cases workbench) and website audit results are saved to your account. Repository suites, statuses and cycles are not. Results from your own test pipeline cannot be uploaded to GoQA; a pipeline can start a GoQA website audit through the API.

Teams — creating a team and inviting members

Any signed-in account can create a team in Settings → Team and add members by email with a role (admin, editor or viewer). GoQA does not send an invitation email: it shows a join link, which you send to the person yourself. When they open it while signed in with that email's account, they join the team. The team owner sees pending and active members and can change a member's role or remove them.

Roles

A member's role (admin, editor or viewer) is recorded on the team and shown in the member list. Roles do not grant or restrict access to anything yet, because teams do not share data (next section).

What teams share

Nothing yet. Test cases, website audit results, scheduled audits, notification settings and credits belong to the account that created them, and row-level security keeps them visible to that account only — also between members of the same team. There is no shared dashboard and no workspace switcher in GoQA's core app. (AI Assurance has its own workspaces, described in its sections above.)

Integrations — CI/CD pipelines

A pipeline can audit a site (for example a staging deploy) and stop the release when the audit finds problems. Create a key in Settings → API keys and store it as a secret in your CI (AWS Secrets Manager, Parameter Store or GitHub secrets), never in the repository. API audits use your plan's pages and credits like scheduled audits, run one at a time per account (up to 3 queued), and also send your notifications and AWS events (api_audit.completed, api_audit.failed, …).

The audit script

goqa-audit.mjs (Node 18+, no dependencies) starts the audit, waits for it, prints the findings and exits 1 when they cross your thresholds (2 when the audit could not complete, for example out of credits). Options: --fail-on-security high|any|none (default high: high or critical findings fail), --max-accessibility N, --max-broken-links N, --max-visual-changes N (fail when more than N pages changed against the screenshot baseline you set for them; pages without a baseline are not compared), --new-only (apply those limits only to findings the previous audit of the same URL did not have, so known issues do not block every build), --report report.json (save the full report), --junit goqa.xml (JUnit XML with one test per check, for CodeBuild test reports, GitHub test reporters or Jenkins) and --timeout 30 (minutes). On GitHub Actions it also writes a findings table to the job summary and marks failed checks as error annotations. Commit a copy to your repository to pin the version you run.

AWS CodeBuild and CodePipeline

A buildspec.yml for a CodeBuild project (any standard image with Node 18 or later). In CodePipeline, add it as a Test action after your deploy stage; a failed audit fails the action and stops the pipeline.

version: 0.2
env:
  secrets-manager:
    GOQA_API_KEY: goqa/api-key        # a Secrets Manager secret holding the key
  variables:
    GOQA_URL: https://staging.example.com
phases:
  build:
    commands:
      - curl -fsSLo goqa-audit.mjs https://goqa.ai/ci/goqa-audit.mjs
      - node goqa-audit.mjs --fail-on-security high --max-broken-links 0 --report goqa-report.json --junit goqa-junit.xml
reports:
  goqa:                               # shows each check in CodeBuild → Reports
    files:
      - goqa-junit.xml
    file-format: JUNITXML
artifacts:
  files:
    - goqa-report.json

GitHub Actions

- name: GoQA audit
  env:
    GOQA_API_KEY: ${{ secrets.GOQA_API_KEY }}
  run: |
    curl -fsSLo goqa-audit.mjs https://goqa.ai/ci/goqa-audit.mjs
    node goqa-audit.mjs --url https://staging.example.com --fail-on-security high

The API

• POST /api/v1/audits with { "url": "https://…" } → 202 { id, status: "queued", statusUrl }. Limited to 30 per key per hour.
• GET /api/v1/audits/:id → status (queued, running, completed, skipped, failed, cancelled), done, reason, and once completed pages, findings (security, securityHighOrCritical, accessibility, brokenLinks, errors) and reportUrl (opens it in the Dashboard). A completed audit also has baseline (the previous completed audit of the same URL, scheduled or API) and newFindings (the same counts, only for findings that audit did not have: same check, rule or link on the same page); both are null for the first audit of a URL.
• GET /api/v1/audits/:id/report → the full report (goqa.audit-report/v1, the same document as the S3 export); 409 until the audit has completed.

OpenAPI specs

In the Test Cases workbench, choose the OpenAPI spec tab and enter the URL of an OpenAPI 3 document in JSON. GoQA fetches it and turns each operation into lines of text: method and path, summary or description, required parameter names, documented response codes and whether security applies. You can edit that text before generating. Request and response schemas and security scheme details are not read.

Postman collections: the same field takes the address of a Postman collection (v2.0 or v2.1 JSON, for example a raw file on GitHub). Its requests are read as endpoints, with the collection's own variables, path variables and query values. Requests that use a variable with no value, call another host than the collection's main API, or have auth (their own, their folder's or the collection's, or an Authorization or API-key header) are listed as not run. Saved example responses document the status codes, and a JSON example is checked loosely: a field that changes type fails, a missing or extra field does not. Postman environments and test scripts are not used. CI runs (/api/v1/api-checks and the CI script) accept a collection address the same way.

Run API checks (signed in) calls the live API. GoQA requests each GET endpoint once, at the spec's server address or the API address you enter, and checks the answer against the spec:

• the status code is a documented success code (server errors and codes the spec does not list fail; a documented error such as 404 is flagged, since the sample value may not exist),
• an answer documented as JSON is JSON and matches the response schema (type, required fields, allowed values, nested objects and arrays),
• it answered within 3 seconds.

Path and required query parameters use the spec's example, default or first allowed value; an endpoint without one is not called. Endpoints that can change data (POST, PUT, PATCH, DELETE) and endpoints that need sign-in are never called; the list under the results says why each one was left out. A run calls at most 30 endpoints, public addresses only, and uses one crawl credit on the Free and Starter plans. Swagger 2 specs work too.

To check endpoints that need sign-in, open Sign-in for endpoints that need it and enter one header (for example Authorization with Bearer …, or your API key header). Use a test account's credential. It needs an https:// API address that you type, is sent only to that address (dropped if the API redirects anywhere else), and is never saved or logged. Endpoints still answer only to GET. A 401 or 403 then fails the check.Download JUnit XML saves the results for CI dashboards.

Every finished run is saved: Past runs under the panel lists the newest runs of the spec, from the app and from CI, with the endpoints that failed. GoQA keeps your newest 200 runs. The credential header is never part of the saved run.

From CI: with a GoQA API key (Settings → API keys), POST /api/v1/api-checks runs the same checks and answers when they finish (within about a minute). The body is the same as in the app: specUrl, optionally baseUrl and auth. Add ?format=junit for JUnit XML that test reporters fail on; the JSON answer has result "pass" or "fail" (a check that failed or never ran is a fail). A CI run is charged like one in the app.

curl -sS -X POST "https://goqa.ai/api/v1/api-checks?format=junit" \
  -H "Authorization: Bearer $GOQA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"specUrl":"https://api.example.com/openapi.json"}' \
  -o goqa-api-checks.xml

Or use the ready-made script goqa-api-checks.mjs (Node 18+, no dependencies): node goqa-api-checks.mjs --spec https://api.example.com/openapi.json --junit results.xml. It prints each endpoint, exits 1 when a check fails or does not run (--strict also fails on "to check" results), and on GitHub Actions writes a job summary. For endpoints that need sign-in, set GOQA_API_CHECK_AUTH to one header (for example Authorization: Bearer … of a test account) and pass --base https://….

Response times: under Response times, choose up to 5 requests per endpoint and optionally a time budget in milliseconds. Each endpoint is called that many times, one request after another (at most 60 requests a run, so large specs get fewer), and judged on its typical (median) time: over the budget fails, and without a budget over 3 s is marked to check. The results show the typical and the slowest time. Every endpoint is checked once first, then the extra requests use the time left. Only the first request is checked against the spec; later ones must get the same status (a 429 fails: the API refused repeated requests). A timed run counts as two runs toward the hourly limit. This measures response times; it is not a load test. From CI, send "timing": { "samples": 5, "budgetMs": 800 } or pass --samples 5 --budget-ms 800 to the script.

Breaking changes between versions: under the checks, Compare with an earlier version takes the address of the older spec and lists what a client written for it would trip over: endpoints removed, answer fields removed, changed in type or no longer required, parameters or a request body that became required, request values no longer accepted, endpoints that now need sign-in, success statuses or answer bodies no longer documented. Added endpoints and fields, optional parameters, deprecations and a changed declared API address are listed apart. readOnly fields count only in answers and writeOnly ones only in requests; a change of sign-in scheme is not compared. Nothing is called on the API and no credit is used.

From CI, POST /api/v1/api-checks/compare takes oldUrl or oldSpec and newUrl or newSpec (a *Spec is the JSON itself, for example the file in your repository; up to 2 MB each) and answers result "fail" when there is a breaking change. With the script, add --compare-to the earlier version (an address, such as production's spec, or a file); --spec may then be a file, in which case only the comparison runs. Breaking changes fail the build unless you pass --allow-breaking: node goqa-api-checks.mjs --spec openapi.json --compare-to https://api.example.com/openapi.json.

Test case runs from CI

A pipeline can run a saved test case set in a browser and fail the build when a case fails. The set needs a schedule (Run on a schedule on /test-cases, any frequency): a CI run is that scheduled run started now, against the schedule's site, in its browser, with the same credits, Run history and notifications. The schedule keeps its own days and times. The panel shows the set's id once it has a schedule.

With a GoQA API key (Settings → API keys), POST /api/v1/test-runs with {"setId":"…"} starts the run and answers 202 with previousRunAt. A run takes minutes, so poll GET /api/v1/test-runs?setId=… until lastRunAt differs from previousRunAt and state is not "running"; then lastStatus is pass, fail, error, no_credits or interrupted, and summary.cases lists each case run with the step that failed. A set that is running already answers 409 (running), and so does a paused schedule (paused); a set that ran less than 2 minutes ago answers 429. The run starts within seconds, or after the scheduled runs GoQA is busy with.

GOQA_API_KEY=goqa_… node goqa-test-runs.mjs --set <set id> --junit goqa-cases.xml

The script goqa-test-runs.mjs (Node 18+, no dependencies) starts the run, waits for it (--timeout minutes, default 45; if the set is running already it waits for that run first) and prints each case. It exits 1 when a case failed or could not run, or nothing was checked; 2 when the run could not be done (no credits, interrupted, timed out); 3 for setup errors (no schedule, paused, no case with steps, bad key). Up to 10 case runs per run, as for scheduled runs: cases left out are listed with a warning, and --fail-on-not-run fails the build on them. On GitHub Actions it writes a job summary and error annotations.

Notification channels

Configure notifications in /settings. Every channel has a “Send test ping” button; a URL that does not belong to its platform is refused on save.

• Slack — an Incoming Webhook URL (hooks.slack.com).
• Discord — a channel webhook URL (discord.com).
• Microsoft Teams — a Teams Workflows URL (“Post to a channel when a webhook request is received”, *.logic.azure.com) or a classic Incoming Webhook (*.webhook.office.com). Messages arrive as an Adaptive Card.
• Google Chat — a space webhook URL (chat.googleapis.com).
• Custom webhook — any public HTTPS endpoint, for example Zapier, Make, n8n or your own service. GoQA POSTs JSON { source, event, title, message, data, sentAt } with an X-GoQA-Event header (crawl.completed, crawl.error, scheduled_audit.completed, test_cases.generated, …). With a signing secret set, X-GoQA-Signature: sha256=<hex> is the HMAC-SHA256 of the raw body with that secret. Private, loopback and cloud-metadata addresses are refused, redirects are not followed, and a request times out after 8 seconds.
• Notify on fail — when a scheduled audit is skipped or fails, when test case generation fails, or when a signed-in crawl stops because its page reservation expired. Findings in an audit do not trigger it.
• Notify on complete — when a signed-in crawl, a scheduled audit or a test case generation finishes, regardless of findings.

Issue trackers: Jira, Azure DevOps, GitHub, Linear

Connect a tracker in Settings → Integrations, then use Create ticket on a security finding, an accessibility violation, a broken link or a generated test case. The ticket gets the finding's details and the page it was found on, and GoQA shows a link to it. Available on every plan.

• Jira Cloud — your site (your-team.atlassian.net), the Atlassian account email, a project key and an API token. Issue type defaults to Task; tickets are labelled goqa.
• Azure DevOps Boards — organization, project and a personal access token with Work Items (Read & write). Work item type defaults to Bug (details go in Repro Steps; other types use Description); tagged GoQA.
• GitHub Issues — owner, repository and a fine-grained token with Issues: Read and write on that repository.
• Linear — a team key (the prefix of issue ids, e.g. ENG) and a personal API key.

Tokens are encrypted (AES-256-GCM) before they are stored, are never shown again after saving (only their last four characters), and are sent only to that tracker's own API. “Test connection” makes a read-only call; “Disconnect” deletes the token. Tickets are one-way: GoQA does not sync status back. To move many test cases at once, export Excel or JSON and use the tool's import.

Amazon Web Services: S3, EventBridge and SNS

In Settings → Integrations, connect AWS with a region and an IAM user's access key (long-term AKIA… keys; the secret is stored encrypted). Fill in only what you want to use:

• S3 bucket — “Export to S3” on a saved audit in the Dashboard writes its report as JSON to <prefix><host>/<date>/<time>-<id>.json (prefix goqa/ by default). With Export every completed audit switched on, signed-in crawls and scheduled audits are exported as they finish. The report (goqa.audit-report/v1) has the summary, pages, security, accessibility, broken links, performance, Web Vitals, Lighthouse, API tests and test scenarios; screenshot images are left out.
• EventBridge event bus — every GoQA event is sent with source goqa and the event name as detail-type: crawl.completed, crawl.error, scheduled_audit.completed, scheduled_audit.skipped, scheduled_audit.failed, test_cases.generated, test_cases.failed. Audit events carry finding counts (findings.security, findings.securityHighOrCritical, findings.accessibility, findings.brokenLinks), so a rule can start a pipeline, a Lambda or a ticket.
• SNS topic — the same events as JSON messages, with an event message attribute for subscription filters. Standard topics only.

Events go out for every outcome, whatever the chat “notify on” switches say. Each delivery is recorded, and the latest show under “Recent notification events” on Test Website. “Test connection” calls STS GetCallerIdentity and shows the account id. A minimal IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-qa-reports/goqa/*" },
    { "Effect": "Allow", "Action": "events:PutEvents", "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/default" },
    { "Effect": "Allow", "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-1:123456789012:goqa" }
  ]
}

Settings — scheduled audits

Settings → Scheduled Audits lists your schedules with their frequency, next run time and last run outcome. You can create a schedule, pause or re-enable it, and delete it. Pausing or deleting a schedule stops an audit that has not finished; audit results already saved stay in your Dashboard. See Scheduled audits.

Notification webhooks

Webhook configuration lives at /settings. Two notification triggers are available — Notify on fail and Notify on complete — for every configured channel. Settings are stored server-side and synced across all devices on your account.

A notification has a title and a short message: the audited URL and page count for a crawl, the reason for a skipped or failed scheduled audit, or the number of generated cases. It does not include grades or finding counts. A schedule's own webhook is notified of every completed, skipped or failed run.

Onboarding tour

The Dashboard shows a five-step tour until you finish or skip it: Welcome, Generate your first test case (link to the workbench), Try the Test Repository, Run an AI site audit, and a final step linking back to the Dashboard. Skip closes it. It cannot be restarted.

Billing & plan

Compare plans and, on the retired Pro plan, manage your subscription at /pricing. Payments are processed by Stripe; card details are never stored by GoQA.

• Enterprise is arranged with sales. Accounts on the retired Pro plan can manage or cancel their subscription from /pricing.
• Refunds: full refund within 30 days of purchase, no questions asked. Email support@goqa.ai.

Usage dashboard

The top of the Dashboard shows:

• Plan name — Starter or Enterprise (or Pro, for accounts still on the retired Pro plan).
• Generations used / limit this month — e.g. “3 / 10” on Starter.
• Progress bar — turns amber at 80% of your monthly limit, red at 95%.
• Upgrade CTA — shown when you are on Starter or nearing your limit.

Free-tier credit usage is tracked server-side and persists across devices. Enterprise is unlimited (so is the retired Pro plan) — the gauge is hidden for those accounts. See Free-tier credits for the full breakdown.

Free-tier credits

Starter accounts get free credits every calendar month to use the platform on real work — no credit card required.

• Credits reset at 00:00 UTC on the first day of each calendar month, whatever your time zone. Unused credits do not roll over.
• Credits are tracked server-side — they persist across devices and browsers and cannot be reset by clearing browser storage.
• Scheduled audits use the same crawl credits as audits you start yourself.
• Each website also has a monthly page quota on Starter (5 pages), shared by audits you start and scheduled audits. Pages count when an audit's result is saved, and deleting a saved result does not give them back. While a crawl of a website is running on your account, a second crawl of the same website is refused with a message to try again when the first finishes.
• An audit that stops with an error before its result is saved, or that saves no pages, gives its crawl credit back.
• The credit gauge on your Dashboard shows remaining credits with colour-coded progress bars (green → amber → red).
• When either credit type is exhausted, the corresponding action is blocked with an upgrade prompt. Enterprise includes unlimited generations and 50-page crawls; use Talk to sales on /pricing.
• Enterprise is unlimited (so is the retired Pro plan) — the gauge is hidden for those accounts.

Report viewer

When you select a saved result in the Dashboard detail panel, GoQA renders a formatted report instead of raw JSON. Two view modes are available:

• Formatted view (default):
  • Test cases — BDD accordion grouped by test type. Each case shows Given / When / Then steps with colour-coded labels and a pass / fail / blocked / skipped status icon.
  • AI audit results — tabbed layout: Summary (stat tiles), Pages, Accessibility (violations grouped by impact: critical → serious → moderate → minor), Security, Performance (navigation / DCL / load times with colour-coded thresholds), Broken Links, and Test Scenarios.
• Raw JSON toggle — click “Raw JSON” in the top-right of the detail panel to switch to the full machine-readable payload. A copy button lets you grab it in one click.

Mobile navigation

On small screens the Dashboard, Test Cases, AI Testing and Settings pages show a fixed bottom bar with Overview, Tests, AI, Automation and Billing. More opens a sheet with all destinations, your account name and Sign out; it closes when you tap a link or the backdrop.

Community Discover feed

The Discover page lists crawl results that signed-in users chose to publish. It is public: anyone can read it without signing in.

• Publishing: tick “Publish results to the public gallery” before starting a crawl. When it completes, GoQA publishes the full URL and hostname, up to 50 crawled page URLs, up to 20 security findings (with their evidence and reproduction commands), accessibility violations with the offending HTML, broken links, SEO and performance data, and Lighthouse scores. Screenshots are not published. Only publish sites you are comfortable exposing that way.
• Deleting your entry: the trash icon deletes an entry you published. On someone else's entry it only hides it in your browser.
• Grades: each card shows a grade from 100 − (8 × security findings + 2 × accessibility violations + 2 × broken links): A ≥ 90, B ≥ 75, C ≥ 60, D ≥ 45, else F.
• Entries scanned against private or loopback hosts are not listed.
• The feed shows sample entries, marked as samples, when there are no published results.

API access

The public API is /api/v1, authenticated with an API key from Settings → API keys in an Authorization: Bearer goqa_… header. It starts website audits and reads their results; see CI/CD pipelines. Other endpoints under /api/ serve the GoQA app itself, accept only a signed-in browser session, and can change without notice, so do not build integrations on them.

Public links

The only resources meant to be opened without signing in are the ones you choose to share: a shareable report URL and its embeddable badge. See Sharing reports and Embeddable badge.

FAQ

1. Can I test a site I don't own?

No. Our Terms of Service allow testing only of websites you own or have explicit written permission to test. Unauthorized testing of third-party infrastructure may be illegal under the Computer Fraud and Abuse Act (USA), Computer Misuse Act (UK), and similar laws in other jurisdictions.

2. Does the security scan modify the target site?

No. All probes are non-destructive read-only HTTP requests. The scanner does not attempt to exploit found vulnerabilities, write data, or modify state.

3. Can I use GoQA from GitHub Actions or another CI system?

Yes, for website audits: a pipeline step can start an audit with an API key and fail the build on security, accessibility or broken-link thresholds (see CI/CD pipelines). Generated test cases are not run by GoQA; export them and run the suite you build from them in your own pipeline.

4. What happens to my data when I move from a paid plan to Starter?

Your saved test cases and audit results stay in your account. From then on Starter's monthly limits apply: 10 AI generations and 5 website crawls of up to 5 pages each. Moving back to a paid plan lifts those limits once your plan is updated.

5. Does the Test Repository keep my suites and runs?

Not yet. The Test Repository is a preview: suites, statuses and cycles stay in the open browser tab and are lost on reload, cycle runs are simulated, and GoQA does not compute flakiness. Export to Excel to keep a copy.

6. What does a shared report show?

A summary: the site, counts of pages, security findings, accessibility issues and broken links, the first findings in each category and a few screenshots. For everything, export the audit and share the file instead.

7. When do scheduled audits run?

After their due time, when GoQA's scheduler next runs. A run uses your plan's crawl limits; if a limit is reached the run is skipped, and Settings → Scheduled Audits shows why.

8. Can I restart the onboarding tour?

No. Once you finish or skip it, it does not appear again.

9. Does the AI Test Coverage Score count other panels or the repository?

No. Each result panel scores only its own cases. See AI Test Coverage Score.

10. Does the badge update after a new audit?

No. A badge belongs to the one shared audit. Share the new audit to get a badge for it.

Design patterns (POM + Factory)

The GoQA codebase deliberately uses two simple, beginner-friendly design patterns so a developer joining the team can read the project on day one. Both patterns live under tests/ and are documented in tests/README.md.

• Page Object Model (POM) — one class per public route, wrapping Playwright locators and user actions.
• Factory pattern — one builder per domain object (User, TestCase, AuditResult, UserSettings) returning fresh, deterministic data.

We resist clever abstractions on purpose. No DI containers, no deep inheritance trees, no decorator magic. If a new contributor cannot understand a page object or factory in under two minutes, we simplify it.

Page Object Model

Page objects live in tests/e2e/pages/. Each route gets one class extending a tiny BasePage shared parent. The class exposes verbs (loginAs, submit) and locator getters (emailInput, errorBanner). Specs do the asserting; pages never call expect().

Currently shipped page objects:

• HomePage, LoginPage, SignupPage
• TestCasesPage, AiTestingPage, TestRepositoryPage
• DashboardPage, SettingsPage
• DocsPage, PricingPage

See tests/e2e/login.pom.spec.ts for a worked example combining POM + factory patterns in a single test.

Factories

Factories live in tests/factories/. Each exposes build(overrides?) returning a deterministic object — same input, same output, every run. No randomness, no Faker.

• userFactory.build() / buildPro() / buildEnterprise() — User fixtures by plan tier.
• testCaseFactory.build() / buildMany(n) — single or batched BDD test cases.
• auditResultFactory.build() / buildClean() / buildFailing() — crawl results in three canonical states.
• settingsFactory.build() — UserSettings with webhook + notification defaults.

Test suite layout

tests/
├── e2e/                   Playwright end-to-end tests
│   ├── pages/             Page Object Model — one class per route
│   └── *.spec.ts          Specs that use page objects + factories
├── factories/             Factory pattern — deterministic test data
├── integration/           API integration tests (Jest + supertest)
└── unit/                  Pure-function unit tests (Jest)

Run all three layers from the project root:

• npm run test:unit — Jest unit suite.
• npm run test:integration — API integration suite.
• npm run test:e2e — Playwright end-to-end suite.
• npm run test:all — runs unit, e2e, and accessibility together.

Automation agent roster

GoQA ships with seven specialized automation agents under .github/agents/. Each agent definition is a Markdown spec a contributor (or another LLM) can read and execute. The roster is tuned for the QA / AI tooling market — every agent has a single, narrow responsibility:

• implementation-agent — ships industry-standard improvements (security, performance, UX).
• testing-agent — verifies the app after each implementation lands.
• fixing-agent — repairs anything the testing-agent flags.
• design-patterns-agent — keeps POM + Factory conventions clean and readable.
• seo-agent — owns technical, on-page, and AI-crawler SEO.
• app-analysis-agent — produces a single GREEN / YELLOW / RED verdict on overall app health.
• feature-suggestion-agent — proposes high-leverage, unshipped features ranked by competitive impact.

Design patterns agent

.github/agents/design-patterns-agent.agent.md enforces the POM + Factory conventions described above. Its job is to:

• Add a page object whenever a new route ships.
• Add a factory whenever a new domain object enters the codebase.
• Refactor any test that constructs objects inline or pokes at locators directly.
• Keep tests/README.md current.

The agent explicitly refuses to introduce DI containers, base-class hierarchies, or decorator magic — readability for new developers is the win condition.

SEO agent

.github/agents/seo-agent.agent.md audits and improves how GoQA is discovered by both classical search engines and AI crawlers. It covers:

• Per-route titles, descriptions, canonicals.
• Structured data: Organization, SoftwareApplication, FAQPage, BreadcrumbList.
• OpenGraph + Twitter card validation.
• Core Web Vitals targets (LCP < 2.5s, CLS < 0.1, INP < 200ms).
• LLM discoverability: explicit allow-rules for GPTBot, ClaudeBot, PerplexityBot plus an /llms.txt summary.
• Keyword-to-page mapping with no duplicate intent.

Success criterion: every primary keyword has a page on SERP page 1 within three months and the home page Lighthouse SEO score is ≥ 95.

App analysis agent

.github/agents/app-analysis-agent.agent.md runs a holistic, end-to-end health check on demand and returns a single verdict — GREEN, YELLOW, or RED — with evidence. It exercises:

• Every public route (200, chrome, console clean).
• Auth flows: signup, login, logout, OAuth.
• Core features: test case generation, AI website crawl, repository workflow, exports, settings, webhooks.
• Every /api/* endpoint: auth, rate limits, schema.
• Integrations: Supabase (with RLS), OpenAI, Stripe, Slack, Discord, Microsoft Teams, Google Chat, custom webhooks.
• Operational signals: /status page, queue health, migrations, advisor warnings, 5xx counts.

Feature suggestion agent

.github/agents/feature-suggestion-agent.agent.md takes a fresh look at the live app and proposes the top ten unshipped features that would make GoQA the obvious leader in its category. Suggestions are ranked across five vectors:

• AI-native moves — self-healing tests, semantic visual diffs, test-impact analysis, conversational authoring, bug-report-to-Playwright reproduction.
• Workflow integrations — GitHub Action, VS Code extension, Linear / Jira two-way sync, CLI, CI plug-ins.
• Coverage upgrades — mobile (Appium) audits, authenticated crawl, API contract drift, localization audit.
• Collaboration & insight — audit history diffs, public trust badges, team workspaces, bounty mode.
• Monetization expansions — usage-based add-ons, white-label, marketplace test packs, paid certification.

Output is structured as one-pagers with effort, impact, why-us, risks, and the smallest shippable v0 — enough for a PM to triage and a senior engineer to scope.

Where to go next