Before any launch, the owner, finance lead and purchasing manager ask one question: will I receive a system that runs my company’s process? The practical answer is acceptance testing, where the people who will use the system run the agreed workflows and the result is clear evidence: what was accepted, what remains open, and what you can rely on from day one. At ToDoOps we build that evidence from cases that represent your transactions, so the launch decision rests on what you have seen for yourself.
How does acceptance testing differ from other testing?
The ISTQB syllabus separates test types in language that carries straight into business use. Acceptance testing checks that the system meets the business need and is ready for deployment, ideally performed by the intended users. Confirmation testing checks that a defect fix worked, and regression testing checks that a change has not harmed related areas or connected systems. Functional testing asks what the system does; nonfunctional testing covers usability, performance and security (ISTQB).
In practice, the user runs their own workflow, and after each fix we repeat the same case and then check the neighbouring workflows. This lets us review the effect of a fix on the connected workflow before accepting it into a release.
What does a good acceptance case look like to an owner?
Take purchasing. In Odoo 19.0 the bill control policy is set per product, based on either ordered or received quantities. Confirming a purchase order makes a draft bill for the ordered quantity available to create; it is an option for the user, not an automatically posted bill. With received quantities, the draft is created from what was actually received, partially or in full. With 3-way matching, a Should Be Paid status appears, and if the price, quantity or lines of a draft are changed, an Exception indication appears (Odoo 19.0 documentation, “Control policies”; reference).
A hypothetical acceptance example: a purchase order for 100 units at SAR 50 per unit, 60 units received, no earlier bill, and the received-quantity policy.
| Situation | Quantity on the draft | Value before tax (SAR) |
|---|---|---|
| Draft from the received quantity | 60 | 3,000 |
| After an authorised user edits it to the ordered quantity | 100 | 5,000 |
| Difference | 40 | 2,000 |
The remaining 40 units await physical receipt, and a pending quantity does not turn into an amount to pay by itself. The stages are separate: draft bill, posted bill, recorded payment, bank settlement. Editing the draft remains possible while the Exception indication appears, so before testing we agree with finance on the review procedure: who may edit a draft, who reviews the indication, and who posts. The purchasing manager then sees what was received, the accountant sees what will be posted, and the owner sees what was actually accepted, instead of a green task status that explains nothing.
How do we test a process across departments?
Real operations cross departments: a sales order is followed by reservation and preparation according to stock settings, then delivery, invoicing and collection according to scope and invoicing policy. We trace the reference, quantity and value along that chain instead of accepting each application alone, so the outcome is clear when the transaction passes between two teams. The Odoo apps pages detail each application, and your industry shows how the cycle differs from one activity to another.
If you want to see how departments connect before going into detail, try Odoo interactively: a guided simulation with fictional data for a sales and inventory path. It also helps accounting and support teams understand a cycle that passes between departments, and it remains an aid to understanding rather than a replacement for testing your own processes.
We also agree on the meaning of each indicator before a report is approved: expected revenue is not collection, quantity is not financial valuation, and a completed task is not the customer’s approval of a progress claim. Once the meanings are written down, a disagreement over a number becomes a specific question with an answer.
What determines the testing effort?
The number of workflows, agreed exceptions, customisations and external integrations, not the number of screens alone. If you want a first view of implementation cost and expected savings before discussing scope, these calculators are an optional aid, and contacting us does not depend on them.
Test environment and access rights
We define a dedicated acceptance-test environment and review isolation of its external connections before starting. Odoo 19.0 documents disabled features such as outgoing email, payment providers and bank synchronisation in neutralised test databases, including test copies and Odoo.sh staging and development. Custom and external connectors are reviewed according to their settings to keep real messages and payments outside this rehearsal (Odoo 19.0 documentation, “Neutralized database”; reference).
We then test with accounts that represent the intended users, not the administrator account alone. Approval authority in the company is a management decision, and the software role is its translation. So we write the approval matrix with you first, then verify that each user sees, edits and approves only what belongs to them (Odoo 19.0 documentation, “Access rights”; reference).
Exceptions and defects
We include the cases that actually occur in your business: returns, cancellations, partial deliveries, a record rejected by an integration, and duplicate requests. Each case needs an understandable outcome and an agreed handling route, including checks for lost or duplicate transactions during retries.
Each defect is recorded with the original requirement, the actual result, its impact and an owner. After the fix we repeat the original case (confirmation testing) and then check nearby workflows (regression testing). A new request is assessed separately from a defect against an agreed requirement, which keeps scope and schedule clear. The go-live checklist shows how this evidence turns into a decision.
Frequently asked questions
What should we prepare before testing starts? The agreed scope, sample data that represents your business (customers, items and orders realistic in shape), and a list of the exceptions that really happen in your operation.
Who should take part on our side? A user from each main workflow, the finance lead to review accounting impact, and someone with authority to accept on behalf of management.
How do I judge whether the result is enough to launch? When the agreed cases have been run with evidence, critical defects are closed and retested, users have completed their tasks with their own accounts, and whatever remains open has a known impact and owner.
Can we accept a first phase only? Yes, if the phase is a complete workflow that runs on its own, with optional additions left to a later phase.
References
- ISTQB, Certified Tester Foundation Level Syllabus v4.0.1 (15 September 2024), prepared by Renzo Cerquozzi and co-authors as listed in the document. Copyright is acknowledged to the authors and ISTQB. Software testing practice reference: original PDF.
- Official Odoo 19.0 documentation: “Control policies” (vendor bill control), “Neutralized database” and “Access rights”.
Your next step with ToDoOps
A good test lets you take the launch decision knowing what was accepted and what remains. Start by getting to know the ToDoOps solution for Odoo, or talk to us about your process and acceptance cases to discuss a testing scope that represents your work. For a first view of cost and savings, the calculators are there when you want them.