What is QAtesting?
An autonomous, credentialed 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 and a ranked report of user-facing defects.
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, nothing off-origin), and it paces itself and backs off when your server signals it’s busy. 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, accessibility label gaps, and stuck loading states — each with the route, a repro, and an evidence screenshot.
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.
Does it re-scan over time and catch regressions?
Yes — you can turn on a nightly 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 you resolved, and which are still present, with new ones badged. So you can watch fixes land and catch things that come back.
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.
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, it only ever probes backends you name — never a third-party service your pages merely embed — and 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.
Already a customer? See the customer FAQ for how to run and read your scans, or sign in.