An Odoo Upgrade Testing Strategy That Finds Real Problems

Why click-around testing finds nothing

Opening the upgraded database and looking at it tests one thing: whether the interface renders. That is rarely what breaks.

The failures that matter are behavioural and numerical. A method that no longer runs. A field that stopped populating. A report whose total is now computed differently. None of them look wrong on screen, because a wrong number and a right number are the same shape.

So the test has to compare, not inspect.

Use a copy of production, nothing else

The records that break upgrades are old ones. Partners created before you standardised the fields. Orders with a currency you no longer trade in. Products with characters in the reference that somebody pasted from a supplier's spreadsheet in 2019. Entries posted by a person who has left.

A demo database contains none of that. Neither does a subset unless you deliberately select for the awkward cases, which requires already knowing where they are.

Take the whole thing. If the database is too large to copy comfortably, that is a constraint to solve rather than a reason to test on something else, because the size problem will also exist on go-live night.

Write the definition of done before you start

This is the single highest-value step and it costs an hour.

Not "it works". A list, agreed with the people who will sign off, with numbers in it:

• Finance can close a period and the trial balance matches the old version to the cent.
• The warehouse can receive a shipment, pick, pack and ship an order.
• Every integration has completed one full cycle in both directions.
• The five reports the business actually uses produce identical figures.
• One document of each customer-facing type has been generated and read.

Written afterwards, this list is a rationalisation of whatever you happened to check. Written beforehand, it is the thing that makes a go-live decision defensible.

Reconcile, do not inspect

Inspection asks "does this look right". Reconciliation asks "does this equal that". Only the second one produces evidence.

Run the same report in both versions and compare the totals. Count records by state in both and compare. Take one order through the full cycle in each and diff the resulting journal entries. Where numbers differ, you have found something real, and where they match you have earned the right to stop worrying about that area.

Numbers that match are the only test result that survives someone senior asking "are you sure".

Test the things that are not in Odoo

The upgrade scope covers modules. The failure surface is wider.

Every integration is a stakeholder, because field renames between versions are invisible inside Odoo and breaking outside it. So are external reports, BI dashboards, saved exports and any script someone wrote once. None of these appear in a module list, so build the inventory deliberately and give each one a test case.

The same applies to anything that sends: invoice emails, delivery notifications, portal access. These are the failures customers see first.

Make the cycle repeatable

The value of testing is in the second and third rounds, and you only get those if a round is cheap. If preparing a test upgrade takes a week of manual steps, you will do it once and go live on a single data point.

Script the restore, the upgrade and the module installs so a fresh test environment is one command. That work pays for itself the first time you need to re-test after a fix, and again on go-live night when the same steps run for real under time pressure.

What the rehearsal is actually for

The final round is not a test, it is a rehearsal. Same steps, same order, timed, with the people who will be awake for it. What you are measuring is the duration and the sequence, because the go-live window is decided by that number and by nothing else.

Time each phase. Note where you waited. That timing is what tells you whether the cutover fits in a weekend, and it is also the input to a realistic rollback deadline, which has to be decided before anyone starts.