For developers

Keep your editor, your repository and your CI.

Tests are plain Playwright files in your repository. Write them in the editor or coding agent you already use. The vikingQA agent adds tests too, as pull requests. Run them in the vikingQA cloud or in your own CI.

Start free Book a demo

The tools you already use

Editors

VS Code
Cursor
JetBrains
Any other editor

Coding agents

Claude Code
Codex
GitHub Copilot
Any other agent

You commit and push, as always

Your repository

tests/checkout.spec.tsYou
tests/promo-code.spec.tsvikingQA agent

vikingQA reads the same files

vikingQA

Runs every test, shows the results to the whole team, and heals a test when your application changes.

How it fits your workflow

Nothing in your workflow changes, except that tests also arrive as pull requests.

Work in the tools you already use

Use any editor and any coding agent. VS Code, Cursor, a JetBrains IDE, Claude Code, Codex and GitHub Copilot are only examples: every tool that can change a file in a git repository works. Write a test by hand or ask your agent, then commit and push as you do today. vikingQA reads the test from your repository and adds it to the shared test list. You install no plugin and no vikingQA library.

Plain Playwright in your repository

Every test is a .spec.ts file in your git. Agent-written tests arrive as pull requests on a vikingqa/ branch. The agent cannot push to any other branch and cannot force-push. It deletes only its own merged or idle vikingqa/ branches. You merge it yourself, or you turn on automatic merge and vikingQA merges it for you.

Your CI runs it. No proprietary runner.

Run in the vikingQA cloud, or in your own CI: the tests are plain Playwright in your repository. They run with the standard Playwright test runner: on your laptop, in GitHub Actions, in GitLab CI, in any pipeline. Running your committed Playwright tests costs no AI credits. Parallel runs you control, and a vikingQA status check on the commit, are on our roadmap.

Self-healing tests

When your interface changes and a test is out of date, the agent explores the application again, heals the test and opens a pull request. You read a small diff instead of a stack trace, or you let vikingQA merge it. If the application is wrong and not the test, the run tells you so, with evidence.

How your day changes.

BeforeWith vikingQA

Before: A new testing tool means a new editor, a new format and a new runner to learn.
With vikingQA: You stay in your editor and your terminal. A test is a Playwright file in your git.
Before: A business analyst sends you a document and asks for a test.
With vikingQA: The analyst records the flow. You receive a pull request.
Before: You write end-to-end tests after the feature, if there is time.
With vikingQA: The agent writes them from the ticket. They arrive as a pull request, with the feature.
Before: A selector changes and the pipeline is red on Monday.
With vikingQA: The agent explores again, heals the test and opens a pull request. You merge it, or vikingQA does.
Before: You reproduce a failure locally to understand it.
With vikingQA: You open the video, the Playwright trace, the network log and the console log of the run.
Before: Leaving a testing tool means rewriting the suite.
With vikingQA: Every test is plain Playwright in your git. Cancel tomorrow and you keep every test.

The business team's tests arrive as code.

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, functional consultants and key users know the process better than any developer. They record it with the browser extension or describe it in chat. The business team stops asking you to write tests for them. You see their contribution as code, in a pull request.

With the agent

Treat the agent as a colleague who takes the end-to-end tickets. Ask it in chat, or let a failed run, a schedule, or a GitHub or GitLab event trigger it. It works on a vikingqa/ branch and opens a pull request. You merge it yourself, or you turn on automatic merge and vikingQA merges it for you.

Questions developers ask.

Can we write tests in our own editor or with our own coding agent?

Yes. A test is a .spec.ts file in your repository. Write it by hand, or with a coding agent such as Claude Code, Codex or GitHub Copilot, then commit it. vikingQA reads it from the repository. vikingQA has no editor plugin and needs none.

Can the agent push to our main branch?

No. It pushes only to branches that start with vikingqa/. It never force-pushes, and it deletes only its own merged or idle vikingqa/ branches. Each change is a pull request under your branch protection. You merge it yourself, or you turn on automatic merge and vikingQA merges it for you.

What access does vikingQA need to our repository?

On GitHub, you install the vikingQA GitHub App on the repositories you choose. On GitLab, you sign in and select the project. vikingQA reads the tests and opens pull requests (merge requests on GitLab). You can remove the access at any time.

Does the agent respect the suite we already have?

Yes. Connect the repository and your existing Playwright tests become the test list. The agent reads the suite before it writes, and adds to it.

Do we need a vikingQA runner or SDK in our pipeline?

No. The tests run with the standard Playwright test runner. To run them in the vikingQA cloud from your pipeline, call the public pipeline API or use the GitHub Actions guide.

What happens if we cancel?

Nothing happens to your tests. They stay in your repository and keep running in your CI.