Writing a test case from a process description

Drafting test cases from a process description is one of the most productive uses of an LLM in an SAP program. The model is fast at turning prose into steps, and a test analyst is good at spotting what is missing. This lesson builds a prompt for Contoso's standard order-to-cash flow, shows what good output looks like, and lists the checks a test lead must still do.

The input: a process description

Maria wrote this description for the standard sales process in Contoso's quality system CMQ, client 100:

The prompt

Priya's prompt uses the six-part pattern. The tags mark the data; the constraints tell the model what it may and may not assume; the example row fixes the format.

1. Role: You are a senior SAP S/4HANA test analyst writing test cases for user acceptance testing.
2. Task: Write test cases for the process in <process>. Cover the happy path first, then two negative cases.
3. Context: Release SAP S/4HANA Cloud Private Edition 2025; system CMQ client 100; the process description in <process>.
4. Constraints: Use only the data in <process>. Do not invent transaction codes, app IDs, movement types or message numbers; where you need one that isn't given, write [CONFIRM] and add it to a list of open questions. Each step needs an expected result a tester can check on screen.
5. Example: one sample row: Step 1 | Create a standard sales order for Great Lakes Fleet Services, 50 × CMC-ALT-100 | Sales area 1710/10/00 | Order saved; net value 12,000.00 USD; no tax | Screenshot of the saved order.
6. Output format: a table with columns Step, Action, Test data, Expected result, Evidence; then a list titled Open questions.

What good output looks like

A good draft has six to eight steps for the happy path (create order, check price and tax, create delivery, pick, post goods issue, bill, check the accounting document) and expected results a tester can verify: the net value 12,000.00 USD, no tax line, delivery quantity 50, goods issue posted, invoice value 12,000.00 USD. It marks anything it wasn't given, such as the goods issue movement type, as [CONFIRM]. A tester then fills that in from the key-user guide: in SAP S/4HANA, goods issue for an outbound delivery posts movement type 601.

The negative cases are where a model adds real value, because it is good at asking "what could go wrong?". Typical proposals: the material is not defined for the sales area; the customer is blocked for sales; insufficient stock in 171A. A test lead picks the ones that match Contoso's risks and adds expected error messages from the system, not from the model.

Consistency across a team

If ten analysts each write their own prompt, you get ten formats. A shared template with a fixed output format and one or two examples is what makes AI-drafted test cases comparable. OpenAI's guide recommends keeping production prompts versioned like code; for a test team that means the template lives with the test standards, has an owner and a version, and changes go through review.