The Orchestration Plan Is a Function of the Cart, Not the Journey

"It's a service change." That sentence tells you nothing about what you have to complete.

Two orders can carry the same journey name, arrive at the same orchestration plan definition, and give you structurally different work to do. Not different values in the same items. Different items.

Two Shapes Behind One Journey Name

The service change plan has two shapes.

When the new service requires a router update, the plan contains CPE Shipment items — a physical dispatch to drive, with the states that go with it. When no router update is needed, those items are not there at all. The plan goes straight from broadband provision to waiting for broadband activation.

The story describes one journey. There is no mention of branching in it, and nothing in the acceptance criteria hints that the plan can come out two different ways. The branching only exists in the decision log, written down after somebody asked.

So a tester who builds one happy path — say, the router-update scenario, because that is the richer one and it feels like better coverage — never exercises the other shape. And a tester who happens to pick the simpler cart never exercises the shipment path. One of the two branches goes untested every time, and nothing in the story tells you which one you skipped.

The Same Mechanism, One Level Up

Now take a modify order rather than a first activation.

Adding hardware in a modify re-runs the full provisioning machinery. A backup power unit added mid-contract produces a shipment task that has to be driven from dispatched through to proof of delivery, exactly as if the customer were brand new. Nothing about it is lighter because the account already exists.

A subscription-only add-on behaves in the opposite way. It creates no orchestration item at all. It closes purely on the billing side, and there is nothing for a tester to do beyond confirming that nothing was expected.

Those two cases sit next to each other in the same cart type, on the same order record type, under the same word: modify.

Why Juniors Get Both of Them Wrong

Because "orchestration" and "shipment" get filed mentally under first activation. A modify is understood as a cart-and-price change: the customer already has service, so the physical world is presumably already sorted.

That single mental shortcut produces two opposite failures.

The first is the missing action. A hardware-adding modify leaves a shipment item that nobody drives, so the order never completes. The tester sees an order sitting in progress, assumes the environment is slow or the integration is down, and either waits or raises a defect against the wrong layer. The actual answer was a task in the plan waiting for a click.

The second is the phantom action. The tester goes hunting for an orchestration item for the subscription add-on, finds nothing, and treats the nothing as a symptom. Time goes into refreshing the plan, re-running the order, and eventually raising a question about why provisioning did not fire — for a product that was never going to fire it.

Both failures come from the same wrong model. Both are avoidable by asking a different question first.

The Rule

The set of orchestration items you have to complete is a function of the cart's product mix, not of whether the order is a first activation.

The journey name is a label on the front of the story. The plan is generated from what is in the basket. Those two things are related, but only loosely, and the relationship is not documented anywhere a tester routinely reads.

Which means the plan shape is something you predict from the cart — and a prediction you write down before you look is a test, while a prediction you make after looking is a description.

Doing It on Your Next Order

• Write the expected item list before you open the plan. Read the cart line by line and note what each line should produce: physical hardware means a shipment, a network-affecting change means provisioning, a subscription-only line means nothing. Then open the plan and compare. A difference in either direction is a finding — an item you did not expect, or one you expected and did not get.
• Ask two questions of every modify. What hardware did this introduce, and what on this order is subscription-only? The first tells you what you must drive to completion. The second tells you what you must not go looking for.
• Treat each plan shape as its own test case, with the trigger in the precondition. "Service change, router update required" and "service change, no router update required" are two cases, not one case with a note. Write the condition that produces the branch into the precondition field, because that is the only place a future tester will read it.
• When an expected item is absent, decide explicitly whether that is a shape or a defect. Those are the two possibilities and they look identical on screen. The answer comes from the cart, not from the plan, and answering it in writing stops the same question from being re-investigated next sprint.

Why This Escapes Review as Well as Testing

Nobody reviewing a test plan asks how many plan shapes exist, because the story does not present that as a variable. The story presents a journey, and a journey sounds like one path with one outcome.

The branching condition lives in a different artefact from the acceptance criteria, and the artefact it lives in is the one written by whoever asked the hardest questions during refinement. If that person did not ask, the branch is not documented anywhere at all — it exists only in the plan definition and in the behaviour of a live order.

There is also nothing to see when it goes wrong. A plan that skipped a branch does not error. An order missing a driven shipment does not raise anything; it simply stays open, which looks exactly like a slow environment. The absence of an orchestration item is not a symptom, and neither is its presence, until you have said in advance which one you expected.

Look at the last order you tested. Could you have predicted its plan from the cart alone — before you opened it?