Lesson 5 of 6
Testing processes and decisions
10 min
Listen to this lesson
A BPA process is easy to demo and easy to under-test. The demo shows the happy path in five minutes; production finds the reject path, the overdue task, the missing approver and the failed API call. Priya's test plan for Fleet Customer Onboarding treats the process like any other piece of software: decisions tested by boundary tables, every path tested with the right test users, integration tested against the paired S/4HANA client, and evidence kept for sign-off.
Test levels for a BPA process
Path coverage
| Path | Inputs | Expected outcome | Evidence |
|---|---|---|---|
| P1 Approve, no finance | Fleet 60, limit 60,000 | Maria approves; decision says no finance; limit written to CMQ | Instance log, partner credit data in CMQ |
| P2 Approve, finance approves | Fleet 20, limit 60,000 | Dan's task in CMC_FIN_CREDIT; approved; limit written | Task history with comment |
| P3 Finance rejects | Fleet 20, limit 60,000 | Dan rejects with reason; sales notified; nothing written | Notification, no change in CMQ |
| P4 Master data rejected | Any | Maria rejects; process ends; nothing written | Instance on reject branch |
| P5 Senior approval | Fleet 120, limit 150,000 | Task goes to CMC_FIN_CREDIT_SENIOR | Recipient group in task |
| P6 Overdue task | Any | Due date passes; behavior as designed (reminder or escalation) | Task status after due date |
| P7 API failure | Destination down or 4xx | Instance in error; retry after fix writes once | Monitor error and retry |
Path tests for the onboarding process. P6 and P7 are the ones demos never show.
Testing with the right users
Approval tests prove nothing if one administrator approves every task. Wei, the test data and environment lead, provisions named test users for fleet sales, the O2C group and both finance groups, in the identity provider used by the QA tenant. Priya's rule: a tester only acts as the role in the test step. A finance approval done by the O2C test user is a defect in the test, or in the access setup if the system allowed it.
Integration and data
Integration tests start where users start: a business partner created in CMQ client 100 with the sales area 1710 / 10 / 00. Wei keeps a recipe for onboarding test partners, with a naming pattern (for example a "TEST-ONB" prefix in the name) so the instances and partners are easy to find and clean up. Each test checks the S/4HANA side after the process: the credit limit in the partner's credit data matches the approved value, written once.
Automating the regression
After the first release, each new version needs the same paths again. Ravi, the TCoE automation lead, automates the cheap parts: an API-level test that starts the process with fixed inputs through the API trigger in the QA tenant and checks the decision result and end status through the process instance data, and a scripted check of the S/4HANA write-back. Human approval steps are the hard part; the team keeps two paths fully manual (P3 and P6) and drives the others with named test users. Automation does not replace the boundary review: every changed decision row still gets its two boundary values.
Evidence that survives an audit
- The released project version that was tested (version number), and the environment it ran in.
- The decision boundary table with results for each row.
- Per path: instance ID, end status, task history (who approved, when, with which comment).
- S/4HANA evidence: the partner's credit data before and after.
- Defects with their retest results, linked in SAP Cloud ALM to the requirement.
What goes wrong in testing
- Admin approves everything. Role errors reach production.
- Tested version differs. The team tested the editor draft, then released a later version.
- Retry writes twice. A failed instance is retried after the API call had actually succeeded; the limit is written twice or the second call fails.
- Test data left behind. Hundreds of test partners clutter CMQ and confuse the next cycle.
What would you do?
In QA, path P7 shows an instance in error after the write-back action got a timeout. After Sam fixes the Cloud Connector, Priya retries the instance and it completes. What else should she check before closing the test?
- Test decisions with boundary tables, then every process path, then integration with the paired S/4HANA client.
- Approvals are tested by named test users in the right groups, never by an administrator.
- Assert the end status, the branch taken and the data written in S/4HANA.
- Record the released version that was tested; it is the version that must be deployed.
Check your understanding · not graded
Lesson check
1. Which path do demos usually skip that Priya tests as P7?
2. Why must approvals be tested by named role users?
3. An instance was retried after a timeout. What must be checked in S/4HANA?
4. Which evidence identifies what was actually tested?
5. Which instance status means a step failed and can be retried?