What is QAtesting?
An autonomous QA agent. You point it at a site you’ve verified you own and give it a standard user login; it logs in and works through every user-visible page like a real user, then hands you an auditable coverage sitemap, a 0–100 quality score, and a ranked report of user-facing defects. You can also run it without a login, against just your public pages.
What does it cost?
A scan costs one credit. Credits come in packs — 1 for $100, 5 for $350 ($70 each), or 10 for $600 ($60 each) — they work on any of your domains, and they don’t expire. There’s also a $200/month subscription per domain: it covers 4 scans of that domain each month ($50 each), the domain’s monthly scans are used before any credits, and unused ones don’t roll over. A scan that fails costs you nothing — it’s refunded automatically. There’s no free tier, so you’ll need credits or a subscription before your first scan. A public-site scan costs the same as a full logged-in one. Right now a limited launch promo makes your first scan free: use code freescan at checkout on the 1-credit pack (first 20 new customers, through September 2026).
Do I have to give it a login?
Not always. A public-site scan skips login entirely and crawls only the pages any visitor can reach — useful for a marketing site, or for trying it on your app before you hand over credentials. But the login is the point of the product: most of what breaks in a real app breaks behind the login, on pages a logged-out crawler can never see. And if your app signs in through SSO, SAML, or MFA — a flow a username and password can’t drive — you can hand it a logged-in session you captured instead, and it crawls behind that.
Do I have to own the site I scan?
Yes. You claim a domain and prove ownership (a homepage meta tag or a DNS TXT record), and ownership is re-checked live at scan time. QAtesting will not crawl a domain you haven’t verified — it’s a tool for testing your own product, not other people’s.
Is the crawl safe to run against my production site?
The crawl is read-only and bounded to your app’s user experience. A network guard blocks anything that isn’t a normal page navigation: no non-GET requests once logged in, and it will never navigate off your origin or touch a private/internal host — the one exception being a sign-in redirect to an external identity provider (SSO), which it follows so your login can complete, and only ever to a public host. Your pages’ own third-party assets — CDN scripts, fonts, images — load normally, exactly as they would in a visitor’s browser, because otherwise we’d be testing a version of your site nobody sees. It paces itself and backs off when your server signals it’s busy, and it does no recon, enumeration, or probing beyond what a real user would touch.
What does it actually find?
User-facing defects a deterministic pass can catch: console and network errors, broken images and dead links, layout and mobile-overflow issues, placeholder / untranslated / mojibake content, missing or duplicate page metadata, dead interactive controls, forms whose validation never clears or never enforces a required field, slow API calls, and stuck loading states — each with the route, a repro, and an evidence screenshot.
Does it check accessibility and SEO too?
Yes, on every scan — nothing to turn on. Alongside the defect pass it audits accessibility against WCAG 2.2 AA (text contrast, touch-target size, heading order, list markup, document language), SEO and mobile hygiene (page title, canonical link, Open Graph tags, mobile viewport), and your security response headers (HSTS, CSP, X-Frame-Options, and friends). Element-level issues are rolled up to one finding per page with the worst offender named, so a low-contrast theme reports as a handful of findings rather than a flood.
Does it work with my single-page app, or does it need a specific framework?
It’s app-agnostic. It drives your app in a real browser, so a JavaScript single-page app and a classic server-rendered site are crawled the same way — it reads the page a user actually sees, not your source. Login uses multiple success signals (URL change, the form disappearing, a new session cookie) so it isn’t tied to any one framework’s login flow.
What do I actually get at the end?
A hosted report: a 0–100 quality score with a trend line across past scans, a Fix first queue of the highest-impact issues, every finding ranked by severity with a repro and an evidence screenshot, a page-by-page drill-down, a panel showing which checks passed as well as which failed, and the coverage sitemap. You can export the findings as CSV or JSON, or print the whole thing to PDF.
Does it re-scan over time and catch regressions?
Yes — you can turn on a weekly re-scan per domain (ownership is re-checked each run), and every report shows what changed since that domain’s last scan: which findings are new, which came back after being fixed, which you resolved, and which are still present, with new and regressed ones badged. So you can watch fixes land and catch things that return.
What if a finding isn’t a real bug?
You triage each finding as confirm, not a bug, or won’t fix. Those labels are durable — they’re keyed to the underlying pattern, so a dismissed finding stays dismissed on future scans instead of nagging you every run. The report gets quieter and more trustworthy the longer you use it.
What’s the coverage sitemap?
A record of exactly what the agent saw — every page it reached, how it got there, which expected routes were and weren’t covered, and any dead-end pages. It’s there so the report is auditable: you can see the scope, not just the findings. There’s a deeper walkthrough of how coverage works.
Can it check security too?
Optionally. An opt-in security lens rides the same authenticated crawl to check whether sensitive data is exposed through your data API and (with a second test login) whether one user can read another user’s data. It’s pure read-only HTTP with no special access. By default it probes the backends your own pages call during the crawl; name your backends explicitly and it probes only those, skipping anything else your pages reference. An inconclusive result is never reported as “secure.” It’s a signal, not a full audit.
What happens to my login and the data it captures?
Credentials are encrypted before storage, and you choose per scan whether to remember them at all. Screenshots and captured evidence are encrypted at rest, and obvious personal data (emails, card and account numbers, tokens) is redacted and masked in the evidence before it’s sealed.
How long do you keep my scans?
Scans and their evidence are deleted 30 days after they run, and you can delete any scan yourself before that. Export anything you want to keep as CSV, JSON, or PDF. One consequence worth knowing: the since-last-scan comparison is built from your stored scans, so it only reaches back as far as that 30-day window. Your quality-score history is kept longer on purpose — the score for each scan of a domain outlives the scan itself, so the trend line still works across months. It holds scores and dates, not screenshots or anything captured from your pages.
Already a customer? See the customer FAQ for how to run and read your scans, or sign in.