What each test checks

Each test in the New run wizard, by the name it shows. For each: what it checks, what you enter, what a pass and a fail mean, and an example. To start a run, see Run a test.

Every test stays on the address you're testing. The descriptions below cover public checks, which start signed out. A public page that answers 401 or 403 ends as missing context, never as a pass. A page that redirects to a sign-in page answers 200 there, so a public smoke test can pass it: list pages that open without signing in.

When saved test sign-in is on, supported manual browser tests can use the application's saved account. When a test you picked supports it, Options asks for the test account email and password, with a protected page that only shows when signed in to prove sign-in worked, and saves them for the next run. A site that signs in through a hosted sign-in service on another address needs that address saved with the account. Options names which tests support Signed-in checks; a test that can't use the saved sign-in runs as public checks, labelled Public checks (ran signed-out). Sign-in is verified before protected pages are judged; a failed or unavailable sign-in never becomes a public fallback. Website sign-in does not configure API authentication. HTTP checks that cannot prove access from the current session remain unjudged. See Run a test to save and select it.

Application setup

When creating a test in Tests, you can select an existing application. Application selection for projects generated from requirements documents is not available yet. The selection belongs to that test project; it does not change the repository’s default project or run settings. Quick setup reuses a project’s selected application. If that selection is unavailable or conflicts with its existing test types, setup stops and asks an administrator to correct the association. If the application was deleted, setup stops and says so. To restore it, open the Applications page at /applications (it isn't in the sidebar while applications aren't linked to runs or services) and add its repository again. A deleted application can't be selected for a new test. If the repository's test is disabled in Tests, setup stops and says so, and doesn't make a new test in its place.

Ready to run

These need only your site's address and the pages to check. Pages starts as /, and you can change it.

Smoke test

The Smoke test checks that each page is up.

• Checks: each page loads, both as a plain request and in a real browser, answers 200, and throws no JavaScript errors while loading.
• You enter: Pages, / by default, up to 10.
• Pass: every page loaded, answered 200, had no JavaScript errors and showed its text, where one was set. Fail: a page answered another status, didn't load, threw an error or didn't show its text.
• Example: /, /pricing, /about-us.

Find pages. For public checks, in the Options step, choose Find pages to list the pages of an address saved for the repository or deployed from it, from its pages, sitemap and app code. Zof only reads them: nothing on your site is run, clicked or submitted. It reads the site's links, its sitemap (and the sitemaps a sitemap index or robots.txt names) and its app code, and offers the home page first, then pages like pricing, sign-up, cart, products, docs and contact, then the rest. Each page says where it was found. It ticks as many as your list has room for; choose Add to put the ticked ones after the pages you typed, which it never changes. Sign-in pages and account areas are listed but can't be added, and links that sign out, delete or cancel are never opened. If it finds only the home page, it says so. Find pages opens only those addresses, by name: an address that is an IP number is refused. Where it reads a page's heading, the smoke test also checks that the page shows that text. A page with no heading found is only checked to load without script errors, which is weaker.

That describes public discovery. With a supported saved test account selected, Find pages signs in once and visits protected pages in a browser. Only protected pages it actually visits are offered as signed-in discoveries, marked with the account version. It performs no forms or site actions after sign-in and still avoids sign-out and destructive links. Signed-in Smoke judges the browser page; ordinary HTTP checks that cannot use the saved session remain unjudged.

Single-page apps. Some sites answer every address with the same page, including made-up ones. On those sites a 200 only proves the server is up, not that the page you named exists. Find pages tells you when your site is one of these. To check a page's own content, use an end-to-end test with open /pricing and then expect "Simple pricing", using text that only that page shows.

Latency test

The Latency test measures how fast each page answers, one request at a time. It isn't a load test.

• Checks: each page is requested 20 times, one after another, after one warm-up request that doesn't count.
• You enter: Pages, / by default.
• Pass: the average answer is under 1 second and 95% of answers are under 2 seconds. Fail: a page is slower than that.
• Example: / and /search.

On a single-page app this measures the page shell, not the data the page loads afterwards.

Accessibility test (WCAG 2.1 AA)

The Accessibility test (WCAG 2.1 AA) is an accessibility audit.

• Checks: each page against WCAG 2.1 AA, at mobile and desktop sizes: automated rules (axe-core), colour contrast, a keyboard walk (focus is visible and nothing traps it), and page basics such as the language, title, image alt text and form labels.
• You enter: Pages, / by default.
• Pass: no serious or critical issue. Fail: at least one serious or critical issue, such as low-contrast text, an image without alt text or a keyboard trap. Moderate and minor issues are listed too. When Verification accepts the run, they show as warnings: only serious and critical issues block, and all four checks must have been judged.
• Example: / and /contact.

Transport security (HTTPS/TLS)

The Transport security (HTTPS/TLS) test checks the secure connection to your address.

• Checks: the secure connection to your address. Old TLS 1.0 and 1.1 and weak ciphers are refused, TLS 1.2 or 1.3 works, the certificate is valid for your host with more than 30 days left, plain http redirects permanently to https, HSTS is set for at least a year, and login forms and session cookies never travel over plain http.
• You enter: nothing beyond your site's address.
• Pass: nothing lets traffic be read or changed in transit. Fail: something does, for example an expired certificate or a missing HSTS header. Weaker settings, such as a temporary redirect to https, are warnings, and a warning also fails the check. A check that can't be tested from Zof is listed and never counts as a pass.
• Example: an address of https://www.example.com checks www.example.com.

Compliance scan (GDPR, PCI, HIPAA)

The Compliance scan (GDPR, PCI, HIPAA) only reads your site; nothing is changed.

• Checks: for each page, the rules of the standard you pick. PCI and HIPAA check HTTPS, the certificate, HSTS and cookie flags; PCI also checks the content security policy. GDPR checks, among others, the privacy policy link and what the policy says, the cookie banner, that no tracking cookies or trackers load before consent, and that rejecting cookies is honoured.
• You enter: a Compliance standard (All, GDPR, PCI or HIPAA) and Pages, / by default.
• Pass: every rule that could be judged passed. Fail: at least one rule failed. Rules that need evidence from inside your system, or a privacy policy the page doesn't link to, are missing context: they count neither as passed nor as failed, and a scan with nothing else to judge reads Couldn't check.
• Example: GDPR on / and /shop.

Visual regression test

The Visual regression test compares screenshots of your pages with ones you approved. It is advisory: never evidence.

• Checks: each page on each device you pick (Mobile, Tablet, Desktop), pixel by pixel against the approved screenshot of that page and device. Up to 5 pages per run.
• You enter: Devices (Desktop and Mobile by default) and Pages, / by default.
• First run: there is nothing to compare with yet, so each screenshot shows Waiting for approval on the run page. Choose Approve as baseline (or Approve all waiting); later runs compare with what you approved.
• Pass: every screenshot is within 0.5% of the approved one and the same size. Fail: a screenshot looks different, or a page didn't render. Each difference is a finding, with the screenshot and an overlay of the changes under Technical details. Approve the new screenshot if the change is intended.
• Example: / and /pricing on Desktop and Mobile. It can't be scheduled yet.

Interface check

The Interface check opens each page in a real browser and looks at it. It never clicks, types or submits.

• Checks: the page's elements, form fields, title, links and console, at one or more screen sizes.
• You enter: Pages, / by default.
• Pass: the page has what it should and its console is clean. Fail: something is missing or broken.

Network test

The Network test loads each page on slow and offline connections. It measures timing, so it takes turns with other timing tests on the address.

• Checks: load time against budgets on each connection, and failed requests.
• You enter: Pages, / by default.
• Pass: every load stays within its budget. Fail: a load goes over it, or a request fails.

Lighthouse lab performance

Lighthouse lab performance runs Lighthouse on each page several times and judges the middle result. It takes turns with other timing tests on the address.

• Checks: lab Largest Contentful Paint, Cumulative Layout Shift and Total Blocking Time.
• You enter: Pages, / by default.
• Pass: each metric is within its limit. Fail: a metric isn't.

Internationalization check

The Internationalization check opens each page in a real browser for each locale.

• Checks: dates, numbers, text encoding and right-to-left layout.
• You enter: Pages, / by default.
• Pass: every selected check holds for every locale. Fail: a value is wrongly formatted, or a layout check doesn't hold.

Broken-link crawl

The Broken-link crawl starts at each page you list and follows your site's own links from there, up to 50 pages and 3 links deep, and stays on that site.

• Checks: every page it reaches and every link on your own site answers below 400.
• You enter: Pages to start from, / by default.
• Pass: no broken link and no failing page. Fail: a link or page answers 400 or above.

Tests that ask for input

The Options step asks for what to check, and nothing is filled in for you.

API contract test

The API contract test checks your API's answers against your API spec.

• Checks: each endpoint is called once, and its answer is compared with your OpenAPI spec: a documented status, the right content type, and a body that matches the schema.
• You enter: API endpoints, one per line, GET only, so nothing on your API changes. Up to 10.
• Pass: every answer matches the spec. Fail: an answer doesn't match it.
• Example: GET /api/products and GET /api/products/1.

Zof reads the spec from your site itself, at the first of /openapi.json, /openapi.yaml, /swagger.json, /v3/api-docs or /api-docs that answers. With no spec, the run ends as missing context. See API checks to publish a spec.

End-to-end test

The End-to-end test runs a user journey through your site.

• Checks: a flow through your site in a real browser, step by step: open pages, click, fill in fields, and check what the page shows.
• You enter: User journeys, each with its steps one per line in the step language. Up to 5 journeys, of up to 30 steps each.
• Pass: every step passed. Fail: a step failed; the run shows which one, with a screenshot when a public journey captured one. Signed-in journeys do not save screenshots.
• Example: open /, then click link "See how it works", then expect url /services.

See Write a user journey for the step language.

Tests that run your code

Unit tests

Unit tests run your repository's own unit tests at the run's commit, in Zof's sandbox.

• You enter: nothing. They need no address.
• They can't be scheduled yet: Schedule is off while they're selected.

Tests that need a verified address

These send heavy or probing traffic. Address proof for them is turned off for now: they run on any address you enter, with no Proof needed tag and no tick, so make sure it's one you may test. Schedules still can't run them. Zof will turn address proof back on. Then it runs them only against an address proven to belong to your company, and they show Proof needed again.

While address proof is on, in the Options step, Prove the address shows each address as Proven ✓ or Not yet. An address your repo's GitHub deployments reported is proven already. Otherwise open Prove the address, then run it and prove it with a one-time file on your site or a DNS record. See Verify your address. Tick I'm authorized to test the address. A test whose address isn't proven yet shows Waiting for proof and runs once it is.

These tests run on demand only, with address proof on or off: Schedule is off while one is selected.

Load, endurance, stress and scalability tests send all their traffic from Zof's one source. If your site's rate limiting or firewall refuses it with 429 or 403, the test reads Couldn't check, never a pass: see Let Zof's test traffic through.

Load test

The Load test sends many users at once to one page.

• You enter: the Path, Users at once (100 by default, up to 200) and Minutes (5 by default, up to 15). Each user waits 1 second between requests. The limits are the p95 answer time and the error rate, and the average answer must also stay under 1,000 ms.
• Pass: the answers and the error rate stay within the limits. Fail: a limit is crossed.

Endurance (soak) test

The Endurance (soak) test sends steady traffic to your address for a long time and measures response latency and errors. It does not measure application memory leaks.

• You enter: Users at once (50 by default, the most it allows) and Minutes (60 by default, the most it allows). Set the average answer time, optional p95 answer time and error-rate limits.
• Pass: the answers and the error rate stay within the limits. Fail: a limit is crossed.

Stress test

The Stress test measures baseline traffic, higher traffic and recovery on one endpoint in staging or a performance environment.

• You enter: a same-site Path to test, Profile (traffic spike, sustained overload or step up to a breakpoint), baseline and peak users (50 peak users by default), phase durations, a recovery budget, an optional p95 limit and the maximum error percentage.
• Limits: at most 200 peak users and 300 seconds total, including three seconds to confirm recovery. Breakpoint profiles allow at most 50 steps.
• Pass: the supported traffic and recovery checks meet the limits. Fail: a measured limit or recovery check fails.
• Standard verification requires at least 50 peak users. A smaller run can still measure behavior; the form and review disclose when it may not qualify.

Scalability test

The Scalability test measures one endpoint at increasing concurrent user levels in staging or a performance environment. It does not add server capacity.

• You enter: a same-site Path to test, 2–10 increasing Concurrent user steps from 1 to 200, Seconds per step, an optional p95 limit, the maximum error percentage and an optional minimum scaling efficiency percentage.
• Limits: at most 900 seconds across all steps. Average response time must stay under 1,000 ms. Efficiency compares successful throughput per user at the last step with the first.
• Pass: every requested step was measured and its acceptance limits hold. Fail: any measured step crosses a limit. Missing steps cannot establish a complete pass.
• Standard verification requires at least 20 peak users and at most 1% measured errors. The form and review disclose when the plan may not qualify.

SQL injection scan

The SQL injection scan is a security scan (DAST). It probes your pages' query parameters and GET forms with a few fixed requests and looks for SQL errors and timing changes. It only detects: it never extracts or changes data.

• You enter: Addresses to probe, up to 5, each with a query parameter to probe, such as /search?q=lamp. Your API is optional for this scan: leave it empty and Zof probes your site.

Payment idempotency test

The Payment idempotency test checks that a retried payment never charges twice. It is judged by the address's payment ledger, not by the store's own answer. It runs five checks: a lost response, concurrent retries, a retry with a different amount, two independent orders, and a redelivery around the retention window.

• You enter: nothing beyond the address (a verified one, once address proof is back on).
• What the address needs: a payment test mode. That is either a payment lab that declares itself a simulation, or your company's payment test-mode adapter, which must confirm test mode with test data on every run. Zof uses only its own zof-test- keys and refuses live keys. The card says "Needs a payment test mode"; hover it for the full reason. You can tick it only when your company has a payment test-mode adapter set up; until then the card is locked. A company admin sees Set up payment test mode on the card instead, which opens the page to set up the adapter (once it's stored, Admin › Overview links there to change or clear it): the paths on the tested address that the agent calls in test mode, and the body of a test payment. It holds no keys or secrets.
• Pass: each check leaves exactly the charges it should. Fail: a duplicate charge. Without a test mode, the checks read Couldn't check. They never pass.

Other test types

New run lists every test type in its category. The tests listed above can be ticked when the engine has a configured, healthy agent for them.

• Advisory test types, such as browser compatibility and DAST, open their own run; API fuzzing opens in New run. Their results never count as evidence or toward a release. A heavy or probing one, such as DAST or API fuzzing, needs a proven address and the I'm authorized to test tick there only while address proof is on; it's off for now.
• A dimmed type is marked Not available. Hover it for the reason, for example "Not available for your company: the selected agent is not configured."
• When Zof can't check, a type never shows as available. It says so, with Retry.

Tests that need more setup

Regression test

The Regression test sends the same read-only requests (the GET endpoints you list) to your address and to the repo's baseline, and reports what worked on the baseline and doesn't now, or got much slower.

The baseline is a run you chose: open a finished, passing run of the repo and choose Use as baseline (any member can). Choosing another run adds a new version. New run shows the current baseline and, until there is one, marks Regression Not available with "Needs a baseline"; hover it for the full reason. The address you test must differ from the baseline's (for example, staging against production).

Advisory compatibility checks

Device Emulation Testing in AI Agents checks page rendering across selected Chromium, Firefox and WebKit engines and emulated device profiles. It checks page content, layout overflow, console/resource errors and configured visible/control/image assertions. Select stored compatibility cases or create page cases, then choose the requested browser/device coverage. The report lists actual and skipped combinations; incomplete full coverage never becomes a complete pass.

These results remain advisory and never satisfy a release. Mobile profiles are browser emulation, not physical-device certification. Use the dedicated tool described in Run a test; compatibility is excluded from the general verification test wizard.

Mobile app (Android & iOS), the page's second mode, installs a native Android or iOS app build on virtual devices and checks each screen: it must launch, not render blank, and pass its text checks. It is advisory too, and set up as described in Run a test.