Test data ideas and SAP master data rules

AI is good at the combinatorial part of test data: listing equivalence classes, boundaries and combinations faster than a person can type them. It is bad at the part SAP testers spend their days on: knowing whether a given supplier, material and organizational unit actually fit together in a specific client. So split the job. Let AI propose; let the test client decide.

What to ask for

Technique	Prompt for	Contoso example
Equivalence partitions	Valid and invalid classes for each input	PO net value: up to $25,000; over $25,000; zero; negative
Boundary values	Values on each side of every threshold	$10,000.00 and $10,000.01 for purchase requisition release; $25,000.00 and $25,000.01 for PO approval
Pairwise combinations	A small set covering every pair of values across inputs	Plant 1710 or 1720 × material CMC-RTR-200 or CMC-STA-300 × value class × purchasing group
Data states	Records in each status the process can meet	A blocked supplier, a material not extended to the plant, a closed posting period
Roles	Users with and without the needed authorizations	A buyer who can create but not approve; an approver for a different purchasing group

Classic test design techniques make good prompts for data ideas.

Ask for the reasoning, not just the values: "for each row, name the class or boundary it represents." That makes review fast, because the reviewer checks the logic once and the values follow. ISTQB's generative AI syllabus makes the same point about evaluating AI results: you need a way to judge output, not just receive it.

Validate against SAP master data rules

Every proposed row must survive contact with the test client. In SAP, data has dependencies an AI model can't see: a supplier needs purchasing organization data before you can order from it, a material must be extended to the plant and valuation area, a price needs a purchasing info record or a manual condition, and a posting needs an open period. The data owner checks each row against these rules in CMQ client 100 before any tester relies on it.

The master data a purchase order test needs; an AI-proposed row is valid only if every link exists in the test client.

The Sign-Off Table · thesignofftable.com/academy/sap-aiq-203

ProposeAI lists classes, boundaries and combinations with the reason for each row
MapEach row is mapped to real records: supplier, material, plant, prices, users
Check in CMQThe data owner confirms each record exists and fits: extensions, info records, open period, roles
Fill gapsMissing records are created through the agreed data process, not ad hoc by testers
FreezeThe validated data plan is versioned with the test cases it serves
RefreshAfter each client refresh, the plan is rechecked before execution

From AI ideas to a test data plan testers can rely on.

The Sign-Off Table · thesignofftable.com/academy/sap-aiq-203

SAP is moving in the same direction. Its Test Data Management Agent in Cloud ALM, an Early Adopter Care feature at the time of writing, reads the instruction text of manual test cases and returns the business objects and field parameters each test needs, such as the data for a purchase order test, grouped by category, as a basis for sourcing data. It answers "what data does this test need?"; whether that data exists and fits in your client is still a check someone has to make.

What would you do?

An approved AI assistant proposes 24 data rows for the PO approval tests. Six rows use material CMC-STA-300 with purchasing organization 1710 and plant 1720 Chicago. A tester wants to start execution tomorrow with all 24 rows. What should Wei, as the data owner, do?

Hands-on lab · ACCELQ

Turn AI-proposed data classes into a Data List and Test Cases

Data Lists hold reusable input values, and a Scenario runs once per Test Case. Here you load AI-proposed classes into a Data List, generate or enter Test Cases from them, and review each row the way this lesson validates data.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first.
Ask an approved AI assistant for search terms for the cart demo's product search in three classes: terms that should return products, terms that should return nothing, and edge cases (one character, mixed case, a trailing space). Ask it to label each term with its class. Keep the list short: three per class.
Open the demo and check every term by hand. Drop or relabel any term whose class the AI got wrong; this is your validation step.
Go to Resources > Data Lists, click +, and create a Data List named Cart search terms with your validated terms.
Create an Action that searches the catalog with an input parameter searchTerm, and set the parameter's acceptable values to your Data List.
Build a Scenario with Initiate Browser Session and your Action. On the Test Cases tab, generate Test Cases from the Data List if your version offers a generation option, or enter one row per term (the label may differ slightly in your version).
Run the Scenario and compare the results with your class labels.

Done when Every Test Case maps to a labeled class, every class has at least one row, and any term the AI mislabeled is noted. Keep the Test Report link and your before-and-after list as evidence of the validation step.

Learn more in ACCELQ’s docs: What is a Data List · Concept of Parameterization and Test Cases

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Let AI propose equivalence classes, boundaries, combinations, data states and roles, with the reason for each row.
Validate every row in the test client against SAP master data dependencies: extensions, info records, open periods and roles.
Version the validated data plan with its test cases and recheck it after every client refresh.
Prompt with synthetic or masked values only; never with production data.

What to ask for

Validate against SAP master data rules

Lesson check