How vikingQA works

vikingQA turns a plain-language description of a test into a real browser test that runs against your application. This page explains how that happens, which components are involved, and what each one sees. It is written for engineers and security reviewers who need to understand the system before approving it. If you are looking for the security controls themselves, see Security and data protection. For our role under GDPR, the subprocessor list and NIS2, see Compliance and subprocessors.

​

The short version

You describe a test case. An AI agent opens a real Chrome browser, explores your application, and writes a standard Playwright test script. That script is then executed in an isolated sandbox on a schedule or on demand. You get a pass or fail, with a video, a trace and screenshots. The important architectural point: the agent authors the test once, and the test runs on its own afterwards. Routine runs are ordinary Playwright executions with no model involved.

​

The lifecycle

Steps 2 and 3 involve an AI model. Step 5 does not.

​

Components

​

How a test gets authored

Two things are worth calling out. The model sees your application’s pages. To write a test that clicks the right button, the agent must read the page. It receives an accessibility tree — the structured text of the page — and screenshots. This is the single most important fact for a privacy review, and we treat it that way in Testing with realistic data. The model never sees your credentials. When the agent needs to log in, it writes a placeholder such as {{personas.admin.creds.web.login.password}}. The real value is substituted immediately before the browser action runs, and any occurrence of it is stripped out of the result before the model or the database sees it. The agent works with credential names, never values.

​

How a test runs afterwards

Once you accept a script, it is an ordinary Playwright test. Running it involves no AI model at all: Each run gets its own sandbox. Sandboxes are never shared between organisations and never reused across customers. When a run finishes, or after an idle timeout, the sandbox is destroyed.

​

Reaching your application

Most customers point vikingQA at a staging or test environment on the public internet. Nothing special is required. If your environment sits behind an IP allowlist, you can enable fixed-IP egress. Every browser session and test run for your project then leaves from a single static address that you add to your firewall. If we cannot determine the correct egress configuration for a session, the run fails rather than silently falling back to a shared dynamic address — so an allowlisted environment is never reached from an unexpected IP.

​

The browser extension

The extension is optional. It does two things:

• Record a flow in your own browser and turn it into a test case, so the agent starts from a real user journey instead of exploring blind.
• Capture a manual test run, recording the tab video, console output and network activity while a human tests by hand.

It only records on URLs your project administrator has added to an allowlist, enforced both in the browser and again on our server. Passwords, one-time codes, card numbers and API keys are stripped inside your browser before anything is transmitted, and recording refuses to start if that sanitiser fails its own start-up self-test.

​

Design decisions that matter for review

Tenancy is enforced before application code runs. Every request passes through middleware that validates organisation membership, project access and role from a signed token. A request that fails any of those checks never reaches a handler. Credentials are encrypted with a key the agent does not hold. Customer application logins are encrypted with AES-256-GCM under a key held only by the web application. The agent worker holds a different key for a different purpose and cannot decrypt your logins. The generated artefact is standard Playwright. There is no proprietary format and no lock-in. You can read the script, edit it, and take it with you. The agent runs against your test environment, not your production system. This is a recommendation, not a technical restriction — and it is the single most effective privacy control available to you. We explain why in Testing with realistic data.