For companies that sell software testing

Give each client a suite they can see and keep.

Your testers and the vikingQA agent build one suite per client. The client sees every test, every result and the video. The tests stay in the client's own code repository.

Client projectsBefore the next releaseIllustrative
  • Nordic BikesWebshop · 42 tests
    All passed
  • Atlas LogisticsCustomer portal · 63 tests
    2 failed
  • Maison VerteBooking site · 28 tests
    All passed
Nordic Bikes · WebshopThe client sees the results
  • 18Automation engineers
  • 9Testers and the client
  • 15The agent

42 tests in one suite. Each run has a video and the logs.

The client pays for testing they cannot open.

01

A new client waits weeks for the first automated suite.

02

Fixing broken scripts uses the hours you sold as testing.

03

The client gets a report. The tests leave when your people do.

Built for client engagements

A suite for every client you serve.

01

One project per client

Each client gets a project, with its own suite, environments and encrypted login details. Invite the client with the Customer role. They see only their project: the test cases, the results and the video, and they can run a test by hand.

02

Your testers decide what to cover

A functional tester records a flow in the browser, or describes it in chat. An automation engineer writes a test in the tools they already use, and can review what the agent writes. The agent explores the application, writes the automated test and heals it when the application changes.

03

The suite stays with the client

The tests are stored in a code repository, in a standard open format (Playwright). You keep running the suite for the client, or you hand the repository over when the engagement ends. In both cases the tests keep working, with or without vikingQA.

How an engagement changes.

  • Before: The first automated suite takes weeks of a senior tester.
    With vikingQA: A tester records the critical flows. The agent writes the tests.
  • Before: The monthly hours go to repairing scripts.
    With vikingQA: Self-healing tests: when the application changes and a test is out of date, the agent explores again and heals the test.
  • Before: Status is a slide or a spreadsheet.
    With vikingQA: The client opens the project and sees each test, each result and the video.
  • Before: A consultant leaves, and the knowledge leaves with them.
    With vikingQA: Every test stays in the repository, as plain steps and as code.
  • Before: A failure becomes a meeting and a screenshot.
    With vikingQA: A failed run has the video, the steps and the logs. The agent creates the ticket in Jira or Linear.

Your testers, your client and an agent on one suite.

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 in
  • A promo code gives the discount
  • The order confirmation email is sent
  • The invoice shows the correct VAT
  • A password reset works
  • Checkout accepts a saved card
Stored in your own repository
01

Automation engineers

They add tests as code. They can review each change the agent writes, or vikingQA can add and heal tests by itself. They choose, per project.

02

Functional testers and the client

Your testers record a flow or run a test case by hand. The client's key users join with the Customer role and do the same. They never write code.

03

The agent

It defines test cases, explores the application, writes the automation and heals a test when the screen changes. One senior tester is not copied onto every account.

Questions testing firms ask.

Do our clients take a seat?

No. Seats are for your own team. People with the Customer role need no seat. They see only the projects you share.

What can a client see?

Test cases, results and evidence, and they can run a test by hand. They cannot see your other clients, your settings or your billing.

Who holds the tests?

You or the client. You choose for each project. In both cases the tests are stored in a code repository, in a standard open format (Playwright). A hand-over is a transfer of that repository.

We already have a Playwright suite for a client. What happens to it?

Connect the repository. Those tests become the list. The agent adds to them. Suites written in another tool stay where they are.

Can our engineers review every change?

They can. Anyone on your team can accept a change in vikingQA, or vikingQA can add and heal tests by itself. You choose per project.

The client's application is not public. Can you reach it?

Tests run from a fixed IP address the client can add to an allow-list. Login details are encrypted variables for each environment.

Can the client run the suite in their own pipeline?

Yes. Run the tests on vikingQA, on their infrastructure, or both.

How do we become a partner?

Apply through the partner program. Project-based terms for partners are on our roadmap.

Catch the next bug before your customers do.

Start free with your own application. No credit card.

We build vikingQA with a small group of design partners.Join the design partner program