Chapter 4 Test Database Rehearsal Method

A test database is not for "looking around the interface." It is for simulating real business. Only after real roles, realistic data, and real exceptions have been tested can the company judge whether Odoo is ready for go-live.

This chapter provides a testing method suitable for beginners. Following it helps turn "it feels almost ready" into "these processes have been confirmed."

What Makes Testing Effective

Effective testing is not an administrator clicking a few buttons casually. It should meet at least four conditions:

• Use data close to real business;
• Use real role accounts, not only the administrator;
• Run complete processes, not only create one document;
• Record issues, owners, and resolutions.

If only the implementer or owner tests with the administrator account, many permission issues, handover issues, and exception processes will not be exposed.

Preparation Before Testing

Prepare a minimum data set before testing.

Products can be created from the Sales application's Products menu. Do not start by importing thousands of products for testing, or the problems will be buried under data volume.

Test Roles

Prepare at least these roles:

Each role should log in with its own account. This is the only way to know whether permissions are enough.

Process 1: Sales To Payment

This is usually the first process most companies need to complete.

Customer -> Quotation -> Sales Order -> Delivery -> Customer Invoice -> Payment -> Reconciliation

When creating a quotation in Sales, test at least customer, product, quantity, price, tax, and payment terms.

Testing steps:

1. Sales creates a customer;
2. Sales creates a quotation;
3. Sales adds products, quantities, unit prices, and taxes;
4. Sales sends or prints the quotation;
5. After customer confirmation, convert the quotation into a sales order;
6. Warehouse processes the delivery;
7. Finance creates the customer invoice;
8. Finance registers customer payment;
9. Finance checks receivables and reconciliation status.

Acceptance standard:

Process 2: Purchase To Payment

The purchase process validates vendors, purchase prices, receipts, and vendor bills.

Vendor -> Request for Quotation -> Purchase Order -> Receipt -> Vendor Bill -> Payment -> Reconciliation

Testing steps:

1. Purchase creates a vendor;
2. Purchase creates a request for quotation;
3. Purchase adds products, quantities, and purchase prices;
4. Confirm the purchase order;
5. Warehouse receives goods;
6. Finance creates the vendor bill;
7. Finance registers vendor payment;
8. Finance checks payables.

Acceptance standard:

Process 3: Inventory Count And Transfer

Any company that manages physical inventory must test inventory flows.

Testing steps:

1. Check current stock of a product;
2. Perform an inventory adjustment;
3. Perform an internal transfer;
4. Perform a sales delivery;
5. Perform a purchase receipt;
6. Check whether inventory quantity changes as expected.

Acceptance standard:

If the company uses lots or serial numbers, test traceability and serial number uniqueness separately.

Process 4: Financial Reconciliation

Financial testing should not only check whether invoices can be created. It must also test payments and bank reconciliation.

Testing steps:

1. Create a customer invoice;
2. Register a customer payment;
3. Import or manually create a bank statement line;
4. Match the bank statement line with the payment or invoice;
5. Check whether the receivable is closed;
6. View the aged receivable report.

Acceptance standard:

For domestic Chinese customers, remember that an Odoo customer invoice is an accounting receivable document, not a Chinese tax-control invoice. Confirm separately whether the company needs integration with a tax invoicing platform.

Exception Flow Testing

Testing only the happy path is not enough. Real business always has exceptions.

At minimum, test these cases:

Exception testing is where many problems are discovered. Do not be afraid of making the test database messy. That is what it is for.

Test Issue Log

Every test issue should be recorded. Do not only write "this is wrong" in a chat group; it will be forgotten quickly.

Use a format like this:

Recommended statuses:

• To confirm;
• To do;
• Solved;
• Not handled for now.

"Not handled for now" also needs a reason. For example, the issue belongs to phase-two optimization, or native Odoo does not support it and later customization is required.

Test Passing Standard

Passing the test does not mean there are no issues. It means the key processes are usable and remaining issues have clear handling plans.

Use this standard:

If these standards are not met, do not go live directly.

Difference Between Trial Run And Formal Go-Live

After testing passes, the company can enter a trial run. A trial run is not the same as formal go-live.

During the trial run, the old system can remain available for lookup, but do not keep double entry for a long time. If the same transaction is entered into two systems, the data will eventually fail to match.

Common Pitfalls For Beginners

• Testing only document creation, not later delivery, invoicing, and payment;
• Testing only normal flows, not cancellation, return, or partial payment;
• Testing only with the administrator account, not real role accounts;
• Reporting issues only in chat, without an issue list;
• Using test data that is too casual and very different from real business;
• Changing requirements frequently during testing, so acceptance never finishes;
• Management not participating in report acceptance and discovering definition issues only after go-live.

The purpose of testing is not to prove that the system is perfect. It is to discover in advance which areas need configuration, training, or phase-two optimization. Once problems are visible, the project has already moved forward.