Runs & evidence

Every run comes with proof.

Your tests run in the vikingQA cloud on every release. Each run keeps its video and the full technical logs. When a test fails, nobody has to reproduce it to believe it, and the bug is caught before your customers see it. Run your tests on vikingQA, on your own infrastructure, or both.

vikingQA
Promo code applies the discount
Staging · 0:42
Failed
0:08 / 0:42

Watch the run again, up to the moment it went wrong.

Batches

One batch. One answer to "can we release?"

A batch is one execution of a selection of tests, on one environment, at one commit. Your pipeline, a schedule or a person starts it.

  • Each batch records the environment, branch, commit and app version.
  • Passed, failed and skipped counts sit at the top of the batch.
  • A failed test opens its evidence in one click.
  • Tests run in the vikingQA cloud, each in its own isolated sandbox.
  • You set how many tests run in parallel for each batch.
  • Select by folder, by tag or by test case.
  • A skipped test is reported as skipped. It is not counted as passed.
Evidence

What happened, from seven angles.

01

Video

A recording of the browser for the full run. Jump to the moment a step failed.

02

Playwright trace

The standard Playwright trace. Open it in the trace viewer to inspect the DOM, the actions and the timing at each point.

03

Network log

Each request as a HAR file, with status and timing. See the failed API call behind a failed step.

04

Console log

The errors and messages the page wrote during the run.

05

Steps history

Each step of the test with its status and duration, in the words of the test case. Non-developers read the result without reading code.

06

Screenshots

The page at the moment of failure.

07

Container log

The output of the sandbox that ran the test, for the cases where the problem is not in the page.

From failure to ticket

Once a bug is found, your tools take it from there.

Not every failed test is a bug. The agent reads the evidence first. If the test is out of date, the agent explores again and heals the test. If it is a real bug, ask the agent to create a ticket with the video and the trace, or to tell the team, in the tools you connected.

Flow diagram. A test fails. The agent reads the evidence and answers one question: is the test out of date, or is it a real bug? If the test is out of date, the agent explores your application again and heals the test, and there is nothing for your team to do. If it is a real bug, your integrations take over. For example: create a ticket in Jira or Linear, notify the team in Slack, or update your test management in Xray or Zephyr Scale, which is on our roadmap. Other tools you connect work in the same way.
A test fails
The agent reads the evidence
Test out of date, or a real bug?
Test out of date
Self-healingThe agent explores again and heals the test.

Nothing to do

Real bug
Your integrations take over
Schedules

Run every night. Read the summary with your coffee.

A schedule runs a selection of tests on an environment at the times you set, in your time zone.

  • Select tests by folder, tag or test case. See how many tests will run before you save.
  • When the batch finishes, vikingQA emails a report to the people you name.
  • The report starts with a short AI summary: what failed, what changed since the last run, and where to look first.
  • "Run now" starts the same selection at any moment.
vikingQATo: QA team
06:14

Nightly smoke on Staging: 40 passed, 2 failed

Summary

Two checkout tests failed at the payment step. Both passed yesterday. The network log shows an error from the payment service in both runs.

40 passed2 failed42 tests · 14 min
  • Checkout with a saved cardFailed
  • Checkout with a promo codeFailed
Open the batch
One report

Automated runs and manual runs, side by side.

Some runs are automated. Some are verified by the agent. Some are run by a person with the browser extension. All three produce the same record: a verdict, the steps and the evidence.

  • Automated runs execute your Playwright code in the vikingQA cloud.
  • AI runs let the agent verify a test case that has no automated test yet.
  • Manual runs capture what a tester did by hand, with the tester's verdict and note.

Your release report shows the full picture: what was tested, how, and by whom.

Questions about runs and evidence.

Do runs cost AI credits?

Running your committed Playwright tests costs no AI credits. Credits pay for the agent's work: writing, exploring and healing tests. An AI run, where the agent verifies a test case that has no automated test yet, is agent work and uses credits.

Where do the tests run?

Run in the vikingQA cloud, or in your own CI: the tests are plain Playwright in your repository. In the vikingQA cloud, each run has its own isolated sandbox. Our sandbox provider routes the work to an EU region, and it writes payloads larger than 2 MiB to object storage in the United States. Sandbox execution fully inside the EU is on our roadmap. Private runners inside your network are on our roadmap.

Can we open the trace in the standard Playwright tools?

Yes. The trace is the standard Playwright trace file. Download it and open it in the Playwright trace viewer.

How do retries work?

Retries follow your Playwright configuration. Each attempt is recorded with its own evidence, so you can see a test that passed only on the second attempt.

Can external people see the results?

Yes. Invite them with the Customer role. They see the projects you share, and nothing else.

Can results go to our test management tool?

Not yet. Result and evidence push to Xray Test Executions and Zephyr Scale test cycles in Jira is on our roadmap.

Can we keep evidence longer than the retention period?

Download the files. Evidence is kept for 90 days today. A longer or custom period per plan is on our roadmap.

Catch the next bug before your customers do.

Start free with your own application. No credit card.