For QA automation engineers

AI-written tests that ship like the rest of your code.

The vikingQA agent writes real Playwright and commits it to your repository through a pull request. You merge it yourself, or you turn on automatic merge and vikingQA merges it for you. Run in the vikingQA cloud, or in your own CI. Running a committed test costs no AI credits and needs no vikingQA runner.

Start free Book a demo

Add guest checkout test

vikingqa/guest-checkout → mainChecks passed

tests/checkout/guest-checkout.spec.ts

import { test, expect } from '@playwright/test';

test('Guest checkout', async ({ page }) => {
  await test.step('Add a product', async () => {
    await page.goto('/products');
    await page.getByRole('button', {
      name: 'Add to cart'
    }).first().click();
  });
  await test.step('Check the cart', async () => {
    await expect(page.getByText('1 item'))
      .toBeVisible();
  });
});

The suite is yours. So is all the work.

You spend more time on broken selectors than on new tests.

The long tail never gets automated. There is always a release first.

Nobody else can add a test, so every request waits for you.

Built for how QA teams ship

The agent writes it, your team owns it, your CI runs it.

Tests live in your repository

Every test is plain Playwright, committed to your git. Run in the vikingQA cloud, or in your own CI. Agent-written tests arrive as pull requests on a vikingqa/ branch. You merge each one yourself, or you turn on automatic merge and vikingQA merges it for you.

Programmatic by default, AI only when needed

A committed test is code. It replays the same way on every run, with no model in the loop and no model latency. Running your committed Playwright tests costs no AI credits. Credits pay for the agent's work: writing, exploring and healing tests.

The long tail gets automated

Give the agent the long tail you never had time for: error states, race conditions, flaky third-party steps. It explores the app, writes the test and runs it until it is stable.

For test managers

Requirement, test case, run, evidence. One line.

vikingQA maps each test case to its Xray test or Zephyr Scale key. Every run writes its result and its evidence to the test cycle. Your coverage report in Jira is correct without a manual update. Roadmap

Test cases sync in both directions. Roadmap
Results arrive in the test cycle with video, Playwright trace, network log and console log. Roadmap
Each test case links to its file and commit in your repository.

See all integrations

How your day changes.

BeforeWith vikingQA

Before: A changed button label breaks twelve tests. You fix them by hand.
With vikingQA: Self-healing tests: the agent explores the page again, heals the tests and opens a pull request. You review the diff, or vikingQA merges it.
Before: A colleague describes a flow in a ticket. You translate it into code.
With vikingQA: The colleague records the flow in the browser. The agent writes the test. It arrives as a pull request.
Before: A new feature is "Ready for QA". You start from an empty file.
With vikingQA: The ticket status triggers the agent. A first set of tests is waiting as a pull request. Roadmap
Before: A red run means an hour of reproduction.
With vikingQA: Every run has video, Playwright trace, network log and console log.
Before: You copy results into the test management tool.
With vikingQA: Results and evidence are written to Xray or Zephyr Scale. Roadmap

You stay the owner. You stop being the bottleneck.

DevelopersAdd tests as code.

Business teamClick through a flow, or describe it.

The agentWrites, runs and heals the tests.

One shared test suite6 tests

A customer can log inAdded by developers
A promo code gives the discountAdded by the business team
The order confirmation email is sentAdded by the agent
The invoice shows the correct VATAdded by the business team
A password reset worksAdded by the agent
Checkout accepts a saved cardAdded by developers

Stored in your own repository

With the business team

Business analysts and key users record a flow with the browser extension or describe it in chat. They never open the code. Their contribution reaches you as a pull request. You review it, or you let vikingQA merge it.

With the agent

The agent is a QA colleague that takes the backlog. Ask it in chat, or let a failed run, a schedule or a repository event trigger it. It defines the test case, explores the app, writes the automation and opens a pull request.

Questions QA engineers ask.

We already have a Playwright suite. Do we start over?

No. Connect the repository and your suite becomes your test list. The agent adds to it and maintains it.

Is the output real Playwright, or a format that needs vikingQA to run?

Real Playwright. Each test is a .spec.ts file that runs with the standard Playwright test runner, in your CI or on your machine.

Does a test run use AI?

No. Running your committed Playwright tests costs no AI credits. Credits pay for the agent's work: writing, exploring and healing tests.

What happens when a test fails because the interface changed?

The agent explores the application again, heals the test and opens a pull request. You merge it yourself, or you turn on automatic merge and vikingQA merges it for you.

Can we keep Xray or Zephyr Scale as the system of record?

The Xray and Zephyr Scale integrations are on our roadmap. They sync test cases and write each result, with its evidence, to the test cycle. Today the agent creates and updates issues in Jira.