Custom test cases and steps

Not every Contoso process is SAP standard. The fleet consolidated invoice, a custom warranty-claim step and an interface to the dealer portal all came out of Fit-to-Standard as requirements. These need test cases written by the team, built on custom solution processes or on standard processes with extra activities. This lesson covers how to write activities and actions that a tester can execute without guessing.

The tabs of a test case

Activities: business steps

An activity is a step a business person would recognize: "Create sales order", "Release credit block", "Post goods issue", "Create billing document". For a custom process, add activities in the Structure tab and give each a target, such as the Fiori app or transaction a tester should open. Keep activities at the level of the process flow, not individual clicks.

Actions: instructions plus expected results

Actions are where test quality is won or lost. Each action needs an instruction precise enough that a different tester would do the same thing, and an expected result precise enough that two testers would agree whether it passed.

Mark Evidence Required on actions whose result matters for sign-off or audit: prices, postings, approvals, authorizations. When a tester rates such an action, Cloud ALM requires evidence before the run can be completed. Do not mark every action; evidence fatigue makes testers capture meaningless screenshots.

Custom processes and requirement-driven tests

For customer-specific processes, a process author can model a custom solution process in Process Authoring, with its own flow diagram. Test cases built on it inherit its activities just like standard processes. Where the requirement modifies a standard process, such as the consolidated invoice changing billing, create a test case on the standard process and add or adjust the billing activity's actions. SAP's guidance is that custom logic must be reflected in the relevant standard test cases, so a test still checks the outcome the business now expects.

References and test data

Negative and authorization tests

Custom test cases are also where you write the tests the standard content rarely covers: what should not happen. A test that a user without the billing role cannot release a credit block, or that an order above the credit limit is blocked, proves controls the auditors care about. Write the expected result as the refusal itself, for example "system blocks the order with a credit-limit message; no delivery can be created", and mark it evidence required. Business role tests are part of SAP's implementation test levels for a reason: a process that works for a super-user and fails for the real role is not ready.

Use the References tab for links to the test data sheet, the setup guide, or a document describing prerequisites. Testers should not have to ask which customer or product to use. A reference to "Contoso test data, O2C cycle 1" with named master data and starting stock is worth more than any amount of explanation in chat.