State transitions on SAP documents

SAP documents have lifecycles. A purchase requisition is blocked, then partly released, then released, then converted. A sales order can be credit blocked, released, delivered and billed. These lifecycles are where business control lives, and where a missed configuration setting lets a document skip an approval. State transition testing models a lifecycle as states (the statuses a document can have), events (what a user or the system does), transitions (event moves the document from one state to another) and guards (conditions that must hold for the transition).

The ISTQB syllabus defines several coverage levels. All states coverage visits every state. Valid transitions coverage (also called 0-switch coverage) exercises every valid transition at least once. All transitions coverage exercises every valid transition and attempts every invalid one, checking that the system refuses it. For approval and blocking logic, all transitions coverage is the level that proves control: the valid path shows the process works, the invalid attempts show nobody can get around it.

Purchase requisition release

Contoso uses a classic release strategy with classification for requisitions in plant 1710. Requisitions with a total value over $10,000 need two releases: code P1 (purchasing supervisor) and then P2 (plant manager), with P1 a prerequisite for P2. As SAP's training explains, the first release status is normally blocked, which prevents conversion into a request for quotation or purchase order; the final status must allow follow-on documents. Releases are made individually in the Release Purchase Requisition app or ME54N, or collectively with ME55. An approver can cancel a release with the same code, but only while no follow-on document exists.

A state table makes invalid transitions as visible as valid ones. Each row is a current state, each column an event, and each cell either the next state or "refused". Every refused cell is a test you should attempt.

Two transitions deserve special attention. First, changing a requisition after it is partly or fully released: whether the change is allowed, and whether it resets the release, depends on the changeability setting of the release indicator. Raising the value from $12,000 to $60,000 after full release is a transition the business almost certainly wants to send back for approval. Test it. Second, crossing the threshold by editing: a $9,500 requisition with no strategy that is changed to $10,500 should become blocked.

Sales order blocks and delivery status

On the sales side, Contoso's automatic credit check can block an order for Great Lakes Fleet Services. The credit analyst can release, recheck or reject the credit case in Manage Documented Credit Decisions. Separately, a delivery block or billing block can be set on the order. Model the states as open, credit blocked, released, delivered and billed, and add the invalid events: create a delivery for a credit-blocked order, bill an order whose delivery has no goods issue, remove a block without the authorization to do so. SAP notes that credit checks can run again at delivery or goods issue, so a manually released block can come back later; include that path when your credit rules check at more than one point.

Item statuses form smaller state machines of their own. An order item's delivery status moves from not yet processed to partially processed to completely processed; a delivery's goods movement status follows the same pattern. Partial deliveries are valid transitions, so a 50-unit order shipped as 30 then 20 should pass through "partially processed" and land on "completely processed". A test that ships all 50 at once never visits the middle state.

Fiori apps add one more layer. A well-built app hides or disables actions that are not allowed in the current state: the Release action does not appear for a user without the release code, and a blocked requisition offers no conversion to a purchase order. That is worth a UI test, but it is not proof of the control on its own. The same transition may be reachable from an SAP GUI transaction, a mass-processing job or an API. For high-risk controls, attempt the invalid transition through at least one route that does not depend on the app hiding the button, and confirm the back end refuses it with a clear message.