Automated versus manual QA for complex price list logic in Odoo 15

ERP Odoo
, , , , , , , ,
1

Our team is debating the optimal QA approach for our increasingly complex price list implementation in Odoo 15. We have multiple price lists with tiered pricing, customer-specific discounts, volume-based rules, promotional periods, and currency conversions. Currently, we use a hybrid approach - automated unit tests for basic price calculations and manual testing for edge cases and multi-rule interactions.

The manual testing takes about 4 hours per release cycle and we’re concerned about potential for missed edge cases as our pricing logic grows more sophisticated. However, some team members argue that fully automated testing would be too brittle and time-consuming to maintain given how frequently our business rules change.

What approaches have worked well for others dealing with complex pricing logic? How do you balance test coverage with maintenance overhead? Are there specific Odoo testing patterns that work particularly well for price list validation?

system 2

The brittleness concern is valid but usually points to a test architecture problem, not an inherent limitation of automation.

Structural approach that scales well

Separate your test layer into three tiers:

  1. Pure-logic unit tests — Test price computation functions in isolation using mocked pricelist records. These are fast, stable, and survive business rule changes because they test one rule at a time.
  2. Scenario integration tests — Test multi-rule interactions (tiered + promotional + currency) against a controlled dataset. Use Odoo’s TransactionCase with setUpClass fixtures so the dataset is explicit and version-controlled.
  3. Regression snapshots — Capture known price outputs for representative customer/product/volume combinations. When business rules change, you deliberately update the snapshot, making changes visible rather than silent.

Odoo-specific patterns worth adopting

  • Use product.pricelist’s _compute_price_rule() method directly in tests rather than going through sale.order — this isolates pricelist logic from order-level side effects (verify in your version that this method signature hasn’t shifted).
  • Tag tests with @tagged('pricelist', 'post_install') so you can run the pricelist suite selectively on each release rather than the full suite.
  • For currency conversion edge cases, mock res.currency._convert() to remove dependency on live rate data — this is a common source of flakiness.

On the 4-hour manual cycle

That overhead is your real cost signal. If manual testing takes 4 hours now, model what happens at 2× rule complexity. A well-structured automated suite should reduce per-release validation to under 30 minutes of human review (approving snapshot diffs), with execution time under 10 minutes. The initial build cost is roughly one sprint for a competent developer familiar with Odoo’s test framework — verify this estimate against your team’s Odoo testing experience.

Maintenance overhead mitigation

Keep business rule parameters in test fixture files, not hardcoded in test methods. When a discount percentage changes, you update one file — not twenty test methods.

The hybrid model is correct; the ratio just needs rebalancing toward automation.

Verify with vendor for current pricing.

This draft is based on general Odoo knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

We went full automation for our price lists and it’s been worth it. The key is structuring your tests as data-driven scenarios rather than hard-coded assertions. We maintain a CSV file with test cases (product, customer, quantity, expected price) and the test suite iterates through them. When business rules change, we just update the CSV. Initial setup took two weeks but now adding new scenarios takes minutes.

4

From a BA perspective, I’d advocate for automated regression testing of core scenarios plus manual exploratory testing for new features. Price lists have too many interaction points - product categories, customer segments, date ranges, minimum quantities - to manually verify everything. We use automated tests as a safety net and focus manual QA on validating new business requirements and user workflows. This hybrid approach catches both technical regressions and business logic issues.

5

The brittleness concern is valid but solvable. We use a page object pattern for our price list tests, abstracting the Odoo API calls into reusable methods. When the underlying models change, we only update the page object layer. Our test suite has 200+ price calculation scenarios and maintenance is maybe 2-3 hours per month. The ROI is enormous - we catch pricing errors before they hit production, which used to cost us real money in incorrect customer invoices.

6

Consider property-based testing for price lists. Instead of testing specific scenarios, you define properties that should always be true (e.g., “volume discounts should never increase the unit price” or “promotional prices should never exceed regular prices”). Libraries like Hypothesis can generate hundreds of test cases automatically. This catches edge cases you wouldn’t think to test manually and adapts as your rules evolve.

7

We struggled with this exact issue last year. Our solution was to implement a three-tier testing strategy. Tier 1: Automated unit tests for individual pricing rules using Odoo’s test framework - fast, run on every commit. Tier 2: Automated integration tests for common customer scenarios - run nightly. Tier 3: Manual exploratory testing for new features and complex multi-rule interactions - done during UAT phase. This gives us confidence in core functionality while keeping manual effort focused where it adds most value. We also maintain a living document of pricing business rules that both developers and QA reference.

8

Four hours of manual testing per release is actually quite efficient, but I understand the scalability concern. The sweet spot we found is automating the “known knowns” - scenarios you test repeatedly - while keeping manual testing for exploratory work and new feature validation. For price lists specifically, focus automation on: price rule priority ordering, date range boundaries, currency conversion accuracy, and volume tier thresholds. These are objective and stable. Keep manual testing for subjective validations like “does this pricing make business sense for this customer segment?” Also, involve your business users in manual testing - they often spot issues that pure technical testing misses.

9

Having implemented both fully automated and hybrid approaches across multiple Odoo pricing implementations, I can share what works best. The optimal strategy depends on your change frequency and pricing complexity, but here’s a framework that scales well:

Automation Focus (70-80% of QA effort):

Automate these categories completely:

  1. Core calculation logic - Base price retrieval, discount application, tax calculations
  2. Rule precedence - Which price list wins when multiple apply
  3. Boundary conditions - Date ranges, quantity thresholds, minimum order values
  4. Currency handling - Conversion rates, rounding rules
  5. Regression scenarios - Past bugs that shouldn’t resurface

Structure tests as parameterized scenarios using test fixtures. For Odoo 15, leverage the product.pricelist model’s price_compute() method in tests:

test_scenarios = [
    {'product': 'PROD-001', 'qty': 10, 'partner': 'customer_a', 'expected': 95.00},
    {'product': 'PROD-001', 'qty': 100, 'partner': 'customer_a', 'expected': 85.00},
    # Add scenarios as CSV or JSON
]

Maintain these scenarios in external files so business users can review and update without touching code.

Manual Testing Focus (20-30% of QA effort):

Reserve manual testing for:

  1. New pricing strategies - First implementation of novel business rules
  2. Cross-module interactions - How pricing affects invoicing, reporting, contracts
  3. User experience validation - Is the pricing UI intuitive? Are error messages clear?
  4. Edge case exploration - Scenarios you haven’t thought to automate yet
  5. Business logic validation - Does the pricing align with business strategy?

Maintenance Strategy:

The brittleness concern is real but manageable:

  • Use abstraction layers (helper methods) for Odoo API interactions
  • Version your test data with your code
  • Run a subset of tests (smoke tests) on every commit, full suite nightly
  • When business rules change, update test expectations in batch during the same sprint
  • Track test maintenance time as a metric - if it exceeds 15% of total QA time, refactor your test architecture

Practical Implementation:

For your current 4-hour manual cycle:

  1. Log what you’re testing manually for the next 3 cycles
  2. Identify the repetitive scenarios (probably 60-70% of your time)
  3. Automate those first using parameterized tests
  4. Keep manual testing for the truly exploratory work

You’ll likely reduce manual testing to 1-1.5 hours while increasing overall coverage. The initial automation investment is 2-3 weeks, but ROI appears within 2-3 months through faster release cycles and fewer production pricing errors.

Red Flags for Going Too Far:

  • Test maintenance takes longer than feature development
  • Tests fail frequently due to minor UI changes
  • You’re mocking too much of Odoo’s core pricing logic

The goal isn’t 100% automation - it’s maximizing confidence per hour of QA effort invested.