A Rushed Go-Live Costs More Than a Delayed One
Most Odoo implementation failures are not configuration failures, they are testing failures. Teams skip odoo uat testing because the deadline is looming and the demo looked fine. Then go-live day arrives and the accounting close breaks, the warehouse picker sees the wrong screen, and the CFO is on the phone at 9 p.m. These nine testing methods are the ones Octura runs on every fixed-price engagement. They cost days to set up and save months of post-go-live firefighting. Run them in order; don't skip the ones that feel obvious.
Define Acceptance Criteria Before You Write a Single Test Case
Acceptance criteria are written before the build, not after. For every business process in scope, purchase order approval, customer invoice, manufacturing order, payroll run, agree in writing on what "done" looks like. Odoo's Discuss and Approvals modules can carry the sign-off workflow for each criterion directly in the system. Without documented criteria, UAT becomes subjective: everyone has a different definition of "working" and nobody signs off. Tie your criteria to the same process list you used in discovery.
Unit Test Every Custom Module Against Odoo's Test Framework
Standard Odoo ships with a Python unit-test framework. Any custom module your partner builds must have coverage tests that pass on the staging database before UAT opens. Odoo's automated test runner catches broken overrides, missing field definitions, and access-rights mismatches early. Skipping this step means users find integration bugs, not testers, the worst possible time to learn about them. See Odoo 19 testing framework for how to structure these tests.
Run End-to-End Process Walkthroughs With Real Business Data
Scripted demos with clean test data hide problems that real data exposes. Pull a representative extract from your current system, 90 days of open purchase orders, a sample of active customers, your real chart of accounts, and run every end-to-end process against it. Odoo's Import wizard and the ORM's CSV import handle most data shapes. An end-to-end walkthrough using real vendor names, real part numbers, and real tax codes is the fastest way to surface configuration gaps before go-live.
Validate Tax Calculations for US and Canadian Compliance
Tax misconfigurations are silent and expensive. For US operations, verify that AvaTax or Odoo's native fiscal positions apply the correct rate to each product category and delivery state, including multi-state nexus. For Canadian entities, test GST/HST/QST at the line and invoice level, and confirm that T4/RL1 and CPP/EI payroll calculations match your payroll register. Run these checks with real customer and vendor addresses, a customer in Quebec billed from Ontario has different tax rules than the same transaction billed from Alberta.
Stress-Test User Access Rights and Record Rules
Access-rights errors are the most common UAT surprise. Odoo's record rules and group-based access model can restrict who sees which records, but a misconfigured rule either blocks a user from their own job or exposes confidential data across departments. Test every user role in every module from a real user account, not from the admin account. Specifically test: a purchasing user who cannot approve their own PO, a salesperson who cannot see another territory's prices, and a warehouse operator who cannot post journal entries.
Reconcile Opening Balances Against Your Current System
Data migration is where go-lives die quietly. Before sign-off, reconcile the Odoo trial balance against your outgoing system's trial balance to the penny. Verify open AR aging, open AP aging, inventory on-hand quantities, and fixed-asset net book values. Odoo's Accounting reports and the Inventory valuation report export directly to Excel for side-by-side comparison. Any discrepancy traced before go-live is a configuration fix. Any discrepancy found after go-live is an audit finding. See why implementations fail, data gaps are consistently in the top three reasons.
Run a Parallel Payroll Period if Payroll Is in Scope
Payroll is the one module where a mistake has immediate legal consequences, late or incorrect pay, wrong CPP/EI deductions, missed T4 box allocations. If Odoo Payroll is in scope, run one full payroll period in parallel: compute the same pay period in both the outgoing system and Odoo, and reconcile every employee's net pay, deductions, and employer contributions. Any variance greater than a rounding difference is a configuration error, not a rounding issue. Build parallel-payroll time into your project plan, it takes a full week when done properly.
Execute an Odoo Tour Test Suite for Critical Flows
Odoo's JavaScript tour framework lets you script browser-level automated tests that simulate a user clicking through a workflow step by step. Build tours for your ten most critical flows, create sales order, confirm purchase, receive inventory, post invoice, apply payment. Run them in CI against each configuration change your partner makes. A broken tour catches regressions before users ever touch the staging environment. Detail in Odoo 19 tour tests.
Run a Dry-Run Go-Live Weekend Before the Real One
A dress rehearsal go-live, using a cloned production environment and your full cutover script, removes the biggest risk from the real go-live: the unknown. Walk the cutover script step by step over a Saturday morning, including locking the outgoing system, importing migration files, validating opening balances, and activating the first live transaction. Time every step. Anything that takes longer than expected in the dry run will take longer on the real day too. Document every deviation and fix it before the live cutover. Teams that skip the dry run often spend their first live week in recovery mode. See the first 90 days after go-live for what follows a successful cutover.
How to Evaluate an Odoo Partner's Testing Discipline Before You Sign
A partner who skips testing is a partner who shifts risk onto you. Six questions to ask before signing the engagement:
- Do you write unit tests for every custom module? "We test manually" is a red flag on any project above 50 users.
- Do you run a parallel payroll period on every payroll implementation? Non-negotiable. If the answer is no, keep looking.
- Who writes the UAT scripts? The partner should deliver a populated test-case library, not hand you a blank template.
- Is a dry-run go-live in the fixed-price scope? It must be. Add it to the contract if it isn't.
- How do you handle access-rights sign-off? Look for a documented role matrix and a sign-off process, not "we'll check it works."
- What is your post-go-live hyper-care window? Minimum two weeks of dedicated support after cutover. Anything less is a handoff, not a go-live.
More vetting criteria in ERP implementation FAQ.
Frequently Asked Questions
The questions readers ask us most often on this topic.
What is odoo uat testing and why does it matter?
UAT (user acceptance testing) is the final validation phase where real users run real business processes in Odoo against agreed acceptance criteria before go-live. It matters because configuration errors caught in UAT cost hours to fix. The same errors found after go-live cost days or weeks and damage trust with your team.
How long does Odoo UAT typically take?
For a mid-market implementation covering Accounting, Inventory, and Sales, plan two to three weeks of structured UAT. Add a week for each additional module in scope (Manufacturing, Payroll, etc.). Rushing UAT below this is the most common reason implementations require a second project to fix post-go-live issues.
Who should run Odoo UAT, the partner or the client?
Both. The partner delivers a populated test-case library and resolves defects. The client runs the test cases using real user accounts, not the admin. The client is the only party who can certify that the system matches their actual business process, not the scripted demo version of it.
What should an Odoo UAT test case include?
Each test case needs: a unique ID, the business process it covers, the test steps in order, the input data used, the expected result, and a pass/fail field with the tester's name and date. Acceptance criteria agreed before the build define what pass means. Vague test cases produce vague sign-offs.
Does Odoo have a built-in test framework?
Yes. Odoo ships a Python unit-test framework for server-side logic and a JavaScript tour framework for browser-level UI automation. Both run against a test database and integrate with CI pipelines. Any custom module built for your implementation should have unit-test coverage before UAT opens.
How do I test tax calculations in Odoo for the US?
For US sales tax, either configure Odoo fiscal positions per state or connect AvaTax for automated nexus-aware calculation. Test with real customer addresses across every state where you have nexus, using real product categories. Multi-state nexus errors, particularly after the South Dakota v. Wayfair threshold, are the most common tax compliance mistake in North American Odoo implementations.
What is a dry-run go-live in an Odoo project?
A dry-run is a full rehearsal of the cutover weekend using a cloned production environment and the real cutover script. You lock the source system, import migration files, validate opening balances, and execute the first live transactions, all on a Saturday morning, weeks before the real date. Every step is timed. Deviations are fixed before the live cutover.
Should I run parallel payroll before switching to Odoo Payroll?
Yes, always. Run one full pay period in both your outgoing system and Odoo simultaneously, then reconcile every employee's net pay, deductions, and employer contributions line by line. Any variance greater than a rounding difference is a configuration error. In Canada, CPP/EI mismatches and RL1 box allocations are the most common parallel-payroll findings.
How do I test Odoo access rights properly?
Test from a real user account for every role in scope, not from the admin account. For each role, verify that the user can complete their job, cannot approve their own documents if approval rules apply, and cannot see records outside their access scope (other company, other territory, confidential pricing). Odoo record rules are the most common source of post-go-live access surprises.
What data should I use for Odoo UAT?
Use a representative extract from your current system: 90 days of open transactions, your real chart of accounts, real vendor and customer names, real product codes, and real tax codes. Synthetic test data hides problems that real data exposes, especially around fiscal positions, rounding rules, and multi-currency scenarios.
How many test cases do I need for an Odoo UAT?
A mid-market implementation typically needs 80–150 test cases across all in-scope modules. Prioritise critical-path flows first: order-to-cash, procure-to-pay, record-to-report. Secondary flows (returns, credit notes, adjustments) come next. Regression tests covering your ten most critical flows should automate with Odoo tour tests and run on every configuration change.
What happens if UAT fails a week before go-live?
Push the go-live date. A failed UAT a week before go-live is a sign of a configuration gap, not a testing gap. Going live on a broken system to meet an artificial deadline will cost more in recovery than the delay. A two-week extension to resolve critical defects is always cheaper than a recovery project.