Connect a repository and the suite in it becomes your test list. vikingQA keeps no second copy. It reads your code, runs it, and makes each change through a pull request. You merge it yourself, or you turn on automatic merge and vikingQA merges it for you.
Every test is plain Playwright in your git. Cancel tomorrow and you keep every test.
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();
});
});Connect GitHub or GitLab and select the repository that holds your tests. On GitHub, you install the vikingQA app and grant access to that repository only. On GitLab, you sign in and select the project.
Name your first environment and the branch it follows. Most teams start with Staging on main.
vikingQA reads your Playwright configuration and lists your tests. You see the count before you finish.
No suite yet? Connect an empty repository. The agent and the recorder fill it.
vikingQA does not ask you to import, convert or tag anything again. It reads what your code already says.
| In your repository | In vikingQA |
|---|---|
A test() in a .spec.ts file | a test case |
| The file path | the folder |
Playwright tags such as @smoke | tags you filter and select by |
test.step() blocks | the steps a non-developer reads |
test.skip and test.fixme | a skipped test, reported as skipped |
| A commit | the exact version a run used |
The list stays current. vikingQA syncs when you push, checks again every hour, and syncs before each pipeline run. You can also sync by hand.
An environment is a name and a branch. Staging can follow main while Production follows your release branch. Each environment shows the tests that exist on its branch and runs them at a known commit.
main appears in Staging first. It appears in Production when the branch gets it.vikingQA commits the agent's work to a vikingqa/ branch and opens a pull request against your base branch (a merge request on GitLab). Each later change in the same chat is one more commit on the same pull request. You merge it yourself, or you turn on automatic merge and vikingQA merges it for you.
Every test is plain Playwright in your git. Cancel tomorrow and you keep every test.
@playwright/test and nothing else of ours.npx playwright test runs the suite on your laptop and in your CI.vikingqa/vikingqa/ branchThe product enforces these rules before a push leaves our system. The agent cannot override them, and a push to any branch outside vikingqa/ is refused.
On GitHub, the vikingQA app asks for Contents, Pull requests and Metadata on the repositories you select.
No. Connect the repository and your suite becomes your test list. The agent adds to it and maintains it.
No. vikingQA runs the suite with the Playwright version your repository declares. There is nothing of ours to install in the repository.
Yes. Run in the vikingQA cloud, or in your own CI: the tests are plain Playwright in your repository. You can do both.
Yes. Select the repository and vikingQA follows the Playwright project it finds there.
vikingQA lists the files it could not load and names the spec file that needed each one. Nothing disappears from the list without a reason.
Run results and evidence, test case metadata such as run history, and the agent's chat sessions. It does not store a second copy of your test code as the source of truth.
Nothing happens to your tests. They stay in your repository and keep running in your CI.
Connect a repository and see your suite in vikingQA in minutes.