Lesson 5 of 6
Regression testing configurable products end to end
10 min
Listen to this lesson
A configuration that is congruent on screen can still produce the wrong order. The configuration feeds pricing, the BOM explosion, routing selection, costing, MRP, the production order, the delivery and the invoice. A regression test for a transformed model follows each of those paths for a well-chosen set of configurations and compares the results with a baseline taken from LO-VC before release.
Take the baseline first
The cheapest test oracle you will ever have is the classic model itself. Before the release of each work area, run the full regression set against LO-VC in CMQ and record every result: valuation, consistency status, price and surcharges, BOM components, routing operations and the sales order cost estimate. After release, run the same set against AVC and compare. Once the model is released, the classic baseline is gone for good, so a team that skips this step has to rebuild expected results by hand.
What to cover
| Layer | What to check | How (Contoso) |
|---|---|---|
| Configuration result | Values, derived values, consistency, refused combinations | Simulate Configuration Models app and VA01 / Manage Sales Orders |
| Variant pricing | Surcharges per option, total price, pricing factors | Pricing screen of the sales order item; variant condition records |
| BOM explosion | Selected components and quantities for the configuration | Simulation with plant and BOM application set; BOM in the production order |
| Routing selection | Operations and work centers selected | Production order operations; simulation with plant set |
| Costing | Sales order cost estimate for the configuration | Costing of the sales order item where Contoso uses it |
| Planning and execution | Planned order, production order, goods issue, goods receipt to sales order stock | MRP for the item, then the production order flow from sap-pp-204 |
| Delivery and billing | Configured item delivered and billed at the configured price | Delivery and billing for one configuration per work area |
Regression layers for a transformed configurable product.
In the simulation app, remember the prerequisite that catches new testers: the plant and BOM application must be set in the simulation parameters, or no BOM is shown, and the routing needs the plant too. A tester who forgets this reports "BOM missing" as a defect.
Choose the configurations
Chicago's regression set for WA-CHI-HD had 140 configurations: 35 for value coverage, 48 for dependencies both ways, 22 for the semantic risk register, 30 from order history and 5 edge cases. Each case had an ID, the input values, and the expected results for each layer from the baseline. Business validation by the aftermarket product manager took the 30 history cases.
Keep the regression set as a living asset. Store each case with its input values, the work area, the layers it covers and the baseline results, in the same test repository the program uses for other regression packs (Contoso uses SAP Cloud ALM). After release, the same set becomes the regression pack for every later model change, so a modeler who edits a constraint next year can prove in an afternoon that nothing else moved. Cases that drive the sales order can be automated with the program's standard automation approach; simulation-only cases are usually faster to run by hand in the simulation app.
Reconfiguration and change
- Change a value on an existing item in VA02 and check the price, BOM and consistency again.
- Copy a configured item from a quotation into an order and check that the configuration survives.
- Change a configuration after the production order exists and check that the change process (for example a blocking status or order change management) behaves as designed.
- Configure the same item with two different users' default values to catch hidden procedure defaults.
What would you do?
Ten days before the CMQ release of WA-CHI-HD, Priya learns that the team has comparison results for configuration values but no baseline for prices or BOMs. The release can slip by three days at most. What should she do?
What goes wrong in testing
| Symptom in test | Real cause | Lesson for the test plan |
|---|---|---|
| BOM missing in simulation | Plant or BOM application not set in the simulation parameters | Put the parameters in every test script |
| Price differs by one surcharge | Variant condition key set by a procedure that now runs differently | Compare each surcharge, not only the net price |
| Production order has an extra component | Selection condition depends on a value AVC now derives | Check the BOM in the production order, not only in simulation |
| Cost estimate differs, configuration identical | Costing reads a routing operation selected differently | Include the sales order cost estimate in the baseline |
| Defect cannot be reproduced | Input values were not recorded with the case | Store input values with every case and result |
Symptoms seen in regression of transformed models, and what they teach.
- Capture the LO-VC baseline for every case and layer before release; it cannot be recreated later.
- Cover configuration, pricing, BOM, routing, costing, planning, delivery and billing.
- Build the set from value coverage, dependencies both ways, semantic risks, history and edge cases.
- Test reconfiguration and changes, not only first-time order entry.
Check your understanding · not graded
Lesson check
1. Why must the regression baseline be captured before the work area is released?
2. A tester sees no BOM in the Simulate Configuration Models app. What should be checked first?
3. Which test set best covers dependency risk?
4. Who should sign a work area's regression results at Contoso?