Built for Odoo integrators

Who tests the custom modules before the upgrade?

An upgrade from Odoo 19 to 20, a Studio change, an OCA add-on or your own module can each break a client flow. vikingQA replays the critical flows in a real browser and shows what broke.

Start free Book a demo

Upgrade checkStaging · before go-liveIllustrative

Client flowOdoo 19Odoo 20

Create a quotation from a leadCRM
Confirm a sale order with a custom discountSalesCustom module
Validate a delivery, two-step routeInventoryStudio
Receive a purchase orderPurchase
Post a vendor bill with approvalAccountingOCA add-on
Invoice a delivered orderAccounting

Same flows. New version. 3 failures found before go-live, each with a video.

Today, one person tests that by hand, the week before go-live.

Standard Odoo works. Your customization on top of it is what breaks.

The people who know the client's flows are business people: a functional consultant, a key user, a process owner. None of them writes code.

You learn what broke from the client.

Built for how Odoo teams ship

Cover the flows that break on every upgrade.

Test every upgrade before it goes live

Point the suite at the upgraded staging database and replay every flow before production. You get a list of what passes on the new version and what does not, with a video of each failure. The same suite runs again on the next version.

Test the custom code you shipped

Cover bespoke modules, Studio automations, OCA add-ons and integrations: everything a standard Odoo test plan skips. Standard features also break under real configuration: workflows, approvals, routing. The suite runs on any Odoo environment: a demo database, a staging copy or the client's own configuration.

Real browser tests instead of Tours

Tests run in a real browser across sales, delivery and accounting, the way the client's users work. The suite does not depend on the Odoo version's own test framework, so it survives the upgrade it is there to check. Your tests are stored in your own code repository, in a standard open format. If you cancel, every test stays and keeps running.

Odoo integration

A failed test becomes a task in your Odoo project.

Connect your Odoo with an API key. When a run fails, the agent creates a task in the Odoo project you choose, with the steps, the failed step and a link to the evidence: a video and the full technical logs. Updating the task automatically when the status changes is on our roadmap. Do you manage the project in another tool? The agent also creates the issue in Jira or Linear.

See all integrations

How an upgrade changes.

BeforeWith vikingQA

Before: One consultant clicks through the client's flows by hand.
With vikingQA: The suite replays every flow on the upgraded database, as often as you want.
Before: Nobody knows which custom module the new version broke.
With vikingQA: A list of failures, each with a video and the failed step.
Before: After an Odoo upgrade, somebody repairs the broken test scripts by hand.
With vikingQA: Self-healing tests: when a screen changes, the agent explores Odoo again and heals the test.
Before: A business person explains the flow to a developer, who writes a Tour.
With vikingQA: Anyone who knows the flow records it in Odoo. The agent writes the test.
Before: A Studio change by the client breaks a flow in production.
With vikingQA: The suite runs every night and after every deployment. You know the next morning.
Before: Each client project starts testing from zero.
With vikingQA: The suite grows with every delivery and stays in the repository.

Developers, business people and the agent on one test 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 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

Developers push code

Your Odoo developers add tests as code, the way they work today. Their tools do not change.

Business stakeholders click

Anyone who knows how the client works: for example a functional consultant, a project manager, a key user or a process owner. They open Odoo, open the vikingQA side panel and click through the flow as they do every day. The extension records what they do. The agent turns it into a test case and an automated test. They never write code.

The agent is a QA colleague

It defines the test case, explores Odoo like a user, runs the test and writes the automation. A colleague asks it in chat, or a failed run or a schedule triggers it. Self-healing tests: when Odoo changes and a test is out of date, the agent explores again and heals the test.

For business teams For developers

Questions Odoo integrators ask.

Which Odoo versions and editions does it test?

Any Odoo a browser can open: Community or Enterprise, any hosting. The tests use the interface, like a user, so they do not depend on the version.

We have no developer on the project. Can we still use vikingQA?

Yes. No developer needed. Anyone on your team can accept a change in vikingQA, or vikingQA can add and heal tests by itself. You choose. Run your tests on vikingQA, on your own infrastructure, or both.

Do we install a module in the client's Odoo?

No. The tests run in a browser against the Odoo instance. The integration that creates project tasks needs only an API key.

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

Yes. Tests run from a fixed IP address that you add to the allow-list. Private runners, for an instance with no inbound access, are on our roadmap.

Does this replace Odoo Tours and our Python unit tests?

Keep your unit tests for module logic. vikingQA replaces Tours for end-to-end flows: it tests the full path across applications, in a real browser, on the client's configuration.

Who owns the tests at the end of the project?

Whoever owns the code repository. Your tests are stored there in a standard open format (Playwright). Hand the repository to the client, or keep it for the maintenance contract.