For development agencies

Show clients the quality you deliver.

Give each client project its own test suite. Run it before each delivery, and find what broke before the client does. Show the client the results, and let them take part if you want. The tests stay with the project: you keep running them for the client, or you hand them over.

Client projectsBefore the next deliveryIllustrative
  • Nordic BikesWebshop · 42 tests
    Ready to deliver
  • Atlas LogisticsCustomer portal · 63 tests
    2 failed
  • Maison VerteBooking site · 28 tests
    Ready to deliver
Nordic Bikes · WebshopThe client sees the results
  • 18Your developers
  • 9Consultants and the client
  • 15The agent

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

Quality is what you sell. It is hard to show.

01

QA is the first line the client cuts from the quote.

02

Acceptance testing is a spreadsheet and a long e-mail thread, the week before go-live.

03

Before each delivery, your team clicks through the same flows by hand, again.

Built for client work

Proof of quality for every project you deliver.

01

Let the client see and take part

Invite clients and external testers with the Customer role. They see only their project: the test cases in plain language, the results and the evidence. They can also run acceptance tests by hand.

02

One project per client, a full test run before each delivery

Each client gets its own project, with its own test suite, environments and encrypted login details. Run every test before each delivery: on a schedule, from your pipeline, or with one click. Each run has a video and the full logs.

03

The tests stay with the project

Every test is a plain Playwright file in the project's code repository. Keep running the suite for your client, or hand it over with the project. In both cases the tests keep working, with or without vikingQA.

How a delivery changes.

  • Before: The client hears "we tested it".
    With vikingQA: The client opens the project and sees each test, each result and the video.
  • Before: Acceptance testing runs on a spreadsheet and e-mail.
    With vikingQA: Your developers, the agent and the client's key users add to one test suite. Automated tests run by themselves, and testers run the others by hand. All results and evidence arrive in one place.
  • Before: A fix for one feature breaks another, and the client finds it.
    With vikingQA: The full test suite runs before each delivery. You find it first.
  • Before: The client reports "it does not work" with a phone photo.
    With vikingQA: A failed run has the video, the steps and the logs. The agent creates the ticket in Jira or Linear.
  • Before: When people change on the project, the testing knowledge leaves with them.
    With vikingQA: Every test stays in the project repository. You keep running the suite for the client, or the client takes it over.

Your team, 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

Developers: your own team

They add tests as code with the feature. They can review the tests the agent writes, if you want that. Their tools do not change.

02

Business team: your consultants and your client

Project managers, functional consultants and the client's key users record flows with the browser extension or describe them in chat. They never write code.

03

The agent: the QA colleague on every project

It defines the test cases, explores the application, runs the tests and writes the automation. Self-healing tests: when the application changes and a test is out of date, the agent explores again and heals the test. A project that had no budget for a tester still gets a test suite.

Questions agencies ask.

What can a client see and do with the Customer role?

Only the projects you share. In those projects a client reads test cases, opens results and evidence, and takes part in acceptance testing. A client cannot see your other clients, your settings or your billing.

Do we pay a seat for each client?

No. Seats are for your own team. Clients and external viewers with the Customer role need no seat.

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), and a hand-over is a transfer of that repository.

Can we use it for a client application that is not public?

Yes. Tests run from a fixed IP address that the client can add to an allow-list. Credentials are stored as encrypted variables for each environment.

We have no QA engineer. Can we still use it?

Yes. The agent does the QA work: it defines test cases, explores the application, writes the automation and heals a test when the application changes. It can add each change by itself, or your developers can review it first.

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