Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 7

High-value uses: from specs to checks

11 min

Listen to this lesson

0:00 / 8:33

This course discusses ACCELQ by name. Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

The best early wins for Claude Code in SAP testing aren't flashy end-to-end scripts. They're the slow, text-heavy jobs that sit around automation: turning a functional spec into test cases, planning data, reading a 4,000-line log, or listing what a transport might break. In each of them the agent produces a draft quickly, and a person who knows the process makes it right. This lesson covers six such uses, the prompt pattern that makes them work, and the repository setup that keeps them safe.

UseWhat you give Claude CodeWhat it draftsWho reviews
Test cases and acceptance criteriaA functional spec, user story or process descriptionGiven / When / Then cases, including negative and boundary cases such as a purchase order just above $25,000Key user (Maria for order-to-cash, Dan for finance)
Test data plansThe scenarios plus Contoso master data (CMC-ALT-100, plant 1710, Great Lakes Fleet Services)A data plan: which records each case needs, who creates them, dependencies and refresh risksTest lead and data owner
Defect and log triageMasked failure logs, Playwright trace summaries, short dump text from ST22Clusters of similar failures, likely causes, a draft defect with steps to reproduceThe tester who reproduces it
API and OData checksA published API spec or service metadataScripted checks for status codes, key fields and an authorization failureAutomation engineer, plus Theo for interface semantics
Transport and change-impact reviewTransport object lists, release notes, affected Fiori app IDsA list of business processes likely affected and a suggested regression scopeTest lead and Kenji (ABAP lead)
ABAP Unit draftingThe class under test and its dependenciesA local test class with test doubles for database and external callsThe developer who owns the class

Six uses where a reviewed AI draft saves real time.

A prompt pattern that holds up

Vague prompts produce plausible nonsense: invented field names, transactions that don't exist in your release, data that doesn't match your configuration. A short, structured prompt fixes most of that, and it makes the output easy to review because you asked for the format in advance.

  1. ContextSystem, release, company code, the process and its owner.
  2. InputsPoint to the spec or file; say what is authoritative.
  3. TaskOne job: "draft test cases", not "test the process".
  4. ConstraintsOnly fields and apps named in the inputs; flag anything assumed.
  5. Output formatA table or template you can paste into SAP Cloud ALM.
  6. Self-checkList assumptions and open questions at the end.
A six-part prompt pattern that makes AI drafts reviewable.
The Sign-Off Table · thesignofftable.com/academy/sap-aiq-201

Notice what the prompt forbids: invention. The ASSUMED marker turns a hidden error into a visible question. When Maria reviews the draft, she spends her time on the business rules rather than hunting for fabricated details.

A CLAUDE.md for an SAP test repository

Put the rules every session needs in the repository's CLAUDE.md, which Claude Code loads at the start of each session. Anthropic recommends keeping each file under about 200 lines; /init generates a starting file. Here is the core of Contoso's:

# Contoso SAP test repository
## Context
- System under test: CMQ client 100 (quality). Never CMP or any production host.
- Contoso data: company code 1710, plant 1710 Detroit, sales area 1710/10/00, customer Great Lakes Fleet Services, material CMC-ALT-100.
- Approval rules: purchase requisitions over $10,000 need release; purchase orders over $25,000 need approval.
## How we write tests
- Test cases: Given / When / Then, one business outcome each, plus at least one negative case.
- Playwright: getByRole, getByLabel or getByText first. Never IDs that start with __. No waitForTimeout.
- Each test starts from a fresh browser context and creates or looks up its own data.
## Data and secrets
- Read credentials only from environment variables. Never write them into files, prompts or logs.
- Use only the masked extracts in data/masked/. Never paste production data.
## Commands
- npx playwright test --project=chromium
- npx playwright show-trace test-results/<test>/trace.zip
## Review
- Every generated test carries a REVIEW: <owner> comment until a person signs it off.

Remember the limit you learned in lesson 1: CLAUDE.md is guidance. The hard limits go in .claude/settings.json as permission rules, such as "deny": ["Read(./.env)", "Bash(git push *)"], and in a PreToolUse hook that rejects any command or URL containing a production host name. Anthropic's permission docs add one more caution: Bash rules match the command text Claude writes, so they aren't a security boundary around a program. For enforcement that doesn't depend on wording, turn on sandboxing.

A drafted test case only becomes a test case of record after a key user approves it in SAP Cloud ALM.
The Sign-Off Table · thesignofftable.com/academy/sap-aiq-201

Notes on three of the uses

  • API checks and SAP's API Policy. SAP published a new API Policy on April 27, 2026. SAP's own overview says integration with autonomous AI agents is allowed only through an endorsed SAP architecture, such as the MCP Gateway in SAP Integration Suite. Community analyses place this in section 2.2.2 of policy version 4.2026a. A script Claude Code writes and a person runs is ordinary automation; an agent that plans and executes its own sequence of SAP API calls is the case the policy targets. Treat that line as a compliance check, confirm it with your SAP contract owner, and use published APIs only.
  • Change-impact review. The agent reads object lists quickly and suggests which processes they touch, but it doesn't know your usage data. Confirm its suggestions against your own change-impact tooling and usage statistics before you cut regression scope.
  • ABAP Unit drafting. SAP says ABAP development in Visual Studio Code started in Q2 2026, first in the ABAP Cloud scope, and that its ABAP MCP server for Eclipse and VS Code is generally available to connect third-party tools. Generated test classes still need the design skills from sap-abp-205: test doubles, one behavior per method, and meaningful assertions.

SAP is building AI into its own test tooling too. SAP Learning lists a Joule Test Management Assistant among its migration and modernization assistants, described as scoping testing and creating test cases on SAP Cloud ALM. Its availability for your contract wasn't confirmed when this course was reviewed, so check with SAP before planning around it.

What would you do?

Claude Code drafted 18 test cases for the Contoso credit check from FS-O2C-014. Maria finds that three cases use a field the spec never mentions, and one refers to a Fiori app Contoso hasn't activated. What should Priya do?

Key points
  • Start with text-heavy jobs: test cases, data plans, log triage, API checks, change impact and ABAP Unit drafts.
  • Use a structured prompt: context, inputs, task, constraints, output format and self-check, with ASSUMED markers.
  • Put shared rules in CLAUDE.md and hard limits in permission rules, hooks and sandboxing.
  • Check SAP's API Policy before letting an agent drive SAP API calls, and use published APIs only.

Check your understanding · not graded

Lesson check

  1. 1. Why does the course recommend an ASSUMED marker in test-design prompts?

  2. 2. Where should a rule that must never be broken, such as "never read the .env file", be configured?

  3. 3. According to SAP's own overview of its April 2026 API Policy, how may autonomous AI agents integrate with SAP APIs?

  4. 4. Claude Code drafts an ABAP Unit test class for a pricing helper. Who should approve it before it is committed?