Organizational structure in test design

You now know the units. This lesson shows how to use them when designing and reviewing tests. The core idea is simple: a test is only as good as the org units it uses. A scenario that passes in one company code, plant or sales area can fail in another because of different assignments, master data or configuration.

Why org units make or break a test

Configuration is often maintained per org unit: pricing per sales organization, account determination per valuation area, approval rules per purchasing organization.
Master data is maintained per org unit: customers per sales area, materials per plant and storage location, suppliers per purchasing organization and company code.
Authorizations are granted per org unit: a buyer allowed for plant 1710 may not be allowed for 1720.
Number ranges, output (forms and e-mails) and tax settings can also vary by company code, plant or sales organization.

Building an org-unit matrix

An org-unit matrix lists the org-unit combinations a process uses in production, and marks which ones the test plan covers. Start with production reality: which plants ship, which sales areas sell, which purchasing organizations buy for which plants. Then choose the combinations to test.

Process	Company code	Sales area / purchasing org	Plant	Storage location	Covered in test?
Order-to-cash: alternator sale	1710	1710 / 10 / 00	1710	171B	Yes, test O2C-01
Order-to-cash: spare part sale	1710	1710 / 10 / 00	1720	172A	Yes, test O2C-02
Procure-to-pay: copper wire	1710	Purchasing org 1710	1710	171A	Yes, test P2P-01
Procure-to-pay: packaging	1710	Purchasing org 1710	1720	172A	No: add, or record the risk

A simple org-unit matrix for Contoso

Choosing what to cover

You rarely need every combination. Prioritize by how much business runs through a combination and how different its setup is from the one you already tested. A combination with high volume and its own configuration must be tested. One with low volume and identical setup may be covered by a lighter check or an accepted, documented risk.

Different setup, low volumeTest at least once; failures here surprise people.

Different setup, high volumeMust test fully, with its own test cases.

Same setup, low volumeLighter check or documented risk acceptance.

Same setup, high volumeRun a short confirmation test; the impact of a miss is high.

Prioritizing org-unit combinations for testing.

Writing org units into test cases

Every test case should state its org units explicitly, not leave them to defaults or user parameters. A sales test should name the sales area, delivering plant and shipping point it expects. A purchasing test should name the purchasing organization, purchasing group, plant and storage location. The expected results should include the derived units too: company code, profit center and segment on the journal entries.

A practical checklist for test data

Pick the org-unit combination from the matrix, not from your user defaults.
Confirm the customer is set up for the sales area, or the supplier for the purchasing organization and company code.
Confirm the material exists in the plant and storage location you will use, with stock if the step needs it.
Confirm your user is authorized for those org units.
Write the expected derived units (company code, profit center, segment, shipping point) into the expected result.
After execution, compare the org units on every resulting document with the expected ones.

What would you do?

The project plans to add a third plant, 1730, next quarter. A process owner asks whether the existing order-to-cash tests are enough. What should you recommend?

Key points

Configuration, master data and authorizations are maintained per org unit, so results differ by org unit.
An org-unit matrix lists production combinations and shows which tests cover them.
Prioritize combinations by business volume and how different their setup is.
State org units explicitly in test cases, including derived company code, profit center and segment.