Why UAT Fails on Odoo Projects#
User acceptance testing on Odoo projects fails for a consistent set of reasons:
- Test cases mirror the happy path only - edge cases at role boundaries are never tested
- Testers and developers share the same user account, so access-rights bugs stay hidden
- No one tests the full document lifecycle end-to-end (draft → confirmed → invoiced → paid → reconciled)
- Reports and exports are "approved" visually without verifying the underlying totals
- Multi-company environments are tested with one company only
The 42 test cases below are organized into seven modules. Each is a real scenario, not a feature check. Use separate user accounts for each role, and run every test from draft state with production-realistic data volumes.
Setup: Before You Start#
- Create a dedicated UAT database - not shared with development or staging.
- Load realistic master data: real chart of accounts, representative customers and vendors, at least one item in each product category.
- Create test users that mirror real roles. Minimum:
- Admin (no restrictions)
- Sales manager (sees all records in sales team)
- Salesperson (sees only own records)
- Accounting manager
- Accountant (cannot approve journal entries)
- Warehouse manager
- Warehouse user (pick/pack only)
- Portal customer (external)
- Disable "auto-subscribe" and "auto-follow" settings so the chatter doesn't fill up with noise during testing.
- Document every bug with: user account, steps to reproduce, expected vs. actual behaviour, and a screenshot.
Module 1: Sales#
| # | Scenario | Role | What to verify |
|---|---|---|---|
| 1 | Create a quotation | Salesperson | Can save without required fields being bypassed |
| 2 | Confirm a quotation | Salesperson | Status moves to Sale Order; delivery order created automatically |
| 3 | Try to delete a confirmed order | Salesperson | Should be blocked (cannot delete confirmed SO) |
| 4 | Apply a pricelist discount | Sales manager | Discount appears on PDF, correct amount on invoice line |
| 5 | View another salesperson's order | Salesperson | Should NOT be visible if access rules are team-scoped |
| 6 | View another salesperson's order | Sales manager | SHOULD be visible (manager scope) |
| 7 | Quotation PDF | Admin | No overlapping text, all fields present, company logo visible |
Common failure: Salesperson A can see Salesperson B's orders because the ir.rule was not configured for the sales team. Test this explicitly.
Module 2: Purchase#
| # | Scenario | Role | What to verify |
|---|---|---|---|
| 8 | Create a Request for Quotation | Purchase user | Vendor automatically populated from product vendor pricelists |
| 9 | Confirm a PO | Purchase manager | Bill is created in Accounting after receipt validation |
| 10 | 3-way match | Accounting manager | Bill cannot be paid above received quantity without override |
| 11 | PO with multiple delivery dates | Purchase user | Each line ships on the correct date; backorder created for partial receipt |
| 12 | Vendor bill matching | Accountant | Bill matched to PO without price discrepancy warning when prices match |
Common failure: The "bill control" policy is set to "on ordered quantity" instead of "on received quantity" for products that need 3-way match. The policy setting is per-product-category and is easy to overlook.
Module 3: Inventory#
| # | Scenario | Role | What to verify |
|---|---|---|---|
| 13 | Receive goods | Warehouse user | Stock quant updated immediately; valuation entry created if perpetual |
| 14 | Pick-pack-ship flow | Warehouse user | Each step requires completion before the next step is available |
| 15 | Backorder creation | Warehouse manager | Partial delivery creates backorder; original order shows both |
| 16 | Inventory adjustment | Warehouse manager | Adjustment creates a journal entry for the value difference |
| 17 | Negative stock | Warehouse user | System allows or blocks based on configured behaviour (test both) |
| 18 | FIFO lot traceability | Warehouse user | Correct lot is assigned on delivery based on FIFO rule |
Common failure: Negative stock is allowed in configuration but business rules require it blocked. Always test this with the warehouse user role, not admin - admin typically bypasses route checks.
Module 4: Accounting#
| # | Scenario | Role | What to verify |
|---|---|---|---|
| 19 | Customer invoice lifecycle | Accountant | Draft → Posted → Paid; journal entries correct at each step |
| 20 | Bank reconciliation | Accountant | Statement lines match invoices without creating duplicate entries |
| 21 | Tax computation | Accountant | Tax groups, rounding, and tax included/excluded behave as configured |
| 22 | Multi-currency invoice | Accountant | Exchange rate applied at invoice date; currency gain/loss entry created on payment |
| 23 | Lock period | Accountant | Cannot post to a locked period (test with date set inside locked range) |
| 24 | Lock period bypass | Accounting manager | Manager CAN post to locked period if policy allows |
| 25 | Aged receivables report | Accounting manager | Totals match sum of open invoice lines; no duplicates from partial payments |
| 26 | Balance sheet export | Admin | Excel export totals match on-screen totals |
Common failure: The aged receivables report shows different totals than the account balance report due to unreconciled partial payments. This is a data issue, not a code issue, but it surfaces in UAT when realistic data is loaded.
Module 5: Custom Workflows and Approvals#
| # | Scenario | Role | What to verify |
|---|---|---|---|
| 27 | Approval required above threshold | Salesperson | Order above configured amount goes to "To Approve" status |
| 28 | Approve an order | Sales manager | Approval moves order to confirmed; approval audit trail visible in chatter |
| 29 | Reject an order | Sales manager | Rejection returns order to draft with a chatter note explaining why |
| 30 | Automated action trigger | Admin | Automated action fires on the configured trigger (e.g., status change) |
| 31 | Email notification | Salesperson | Notification email sent to correct recipient on trigger; no duplicate sends |
Module 6: Reports and Exports#
| # | Scenario | Role | What to verify |
|---|---|---|---|
| 32 | Sale order PDF | Salesperson | All custom fields visible; no broken layout on long product names |
| 33 | Invoice PDF | Accountant | Tax breakdown, payment terms, and bank details all present |
| 34 | Delivery slip PDF | Warehouse user | Lot numbers and quantities match the actual transfer |
| 35 | Excel export from list view | Admin | All columns present; no truncation; UTF-8 encoding (accents, special chars) |
| 36 | Pivot report drill-down | Sales manager | Drill-down to individual records matches the aggregated total |
| 37 | Scheduled report email | Admin | Email arrives, attachment opens without error, totals match on-screen |
Common failure: PDF reports look correct on-screen but break layout when the data contains very long strings (e.g., a product name over 80 characters). Test with realistic data, not short demo names.
Module 7: Security and Access Rights#
| # | Scenario | Role | What to verify |
|---|---|---|---|
| 38 | Portal customer view | Portal user | Can see own orders and invoices only; cannot access backend |
| 39 | Portal customer document download | Portal user | Can download own invoice PDF; cannot download another customer's |
| 40 | Admin-only menu visibility | Salesperson | Technical menus (Settings > Technical) are not visible |
| 41 | Record rule bypass attempt | Salesperson | Attempting to access another salesperson's record via direct URL returns 404 or access denied |
| 42 | Export restriction | Accountant | Cannot export the full customer list if the export group is not assigned |
Scoring and Sign-Off#
Create a spreadsheet with all 42 test cases. For each, record:
- Status: Pass / Fail / Blocked / N/A
- Tester: Name and date
- Bug ID: Link to issue tracker entry if failed
Define pass criteria before UAT starts - a common default is: no blocker bugs, no more than 5 open major bugs, all critical business flows passing. Do not sign off UAT with open blockers by labelling them "known issues to fix post-go-live" - that pattern reliably produces missed go-live dates.
ERPeek can accelerate UAT preparation by answering questions like "which ir.rules restrict access to this model?" or "what automated actions fire on sale.order write?" across any installed Odoo version and custom module set. See the contact page for a demo.