Using both: Claude Code as an assistant around the platform

Choosing a platform doesn't mean putting Claude Code away. The strongest setup uses each for what it does best: the platform holds the executable tests, the data, the environments and the evidence; Claude Code works around it as a fast assistant for drafting, analysis and glue code. People stay the decision makers in between. This lesson shows the division of labor, the CI wiring, and the guardrails that keep it safe.

Task	Claude Code	Platform	People
Scenario design	Drafts Scenario outlines in business language, reusing the names of existing Actions	Holds the Scenario, its steps and Test Cases	Key user approves; engineer builds
Test data	Drafts data rows and boundary values from the spec	Stores Test Cases, Data Lists and per-environment Global Properties	Data owner checks against CMQ
Failure analysis	Clusters failures from a masked export, compares runs, drafts defects	Produces the Test Report, screenshots and self-healing detail	Tester reproduces and raises the defect
API checks	Writes OData check scripts or drafts REST call details	Runs REST calls inside Actions with response verification	Theo confirms interface semantics
Pipeline glue	Writes the CI step that triggers a job and waits for status	Runs CI Jobs on Local Agents	Release manager approves the pipeline

Who does what when Claude Code assists around a test platform.

Drafting scenarios and data

Give Claude Code the spec and the list of Action names your TCoE already maintains, and ask for Scenario outlines that reuse them. Asking it to prefer existing Actions over new ones keeps the library small. Ask for Test Case rows with boundary values, such as a purchase order at $25,000 and at $25,000.01. A person then builds or adjusts the Scenario in the platform, where Maria can review it in plain language.

Analyzing failures from reports

ACCELQ can export Test Results as a PDF or Excel workbook, including step-level detail. After a nightly run, an engineer exports the failed results, masks customer names and document numbers, and asks Claude Code to group failures by probable cause, compare them with the previous night and draft defects. The tester then confirms each one and raises it from the result itself, which keeps the defect linked to the Scenario. Treat report text as untrusted input: messages and field values come from the application and could carry injected instructions.

API checks

For OData services, Claude Code can write check scripts against published APIs in your repository, or draft the request details for a REST call that an engineer then builds in the platform with + API > Insert REST call. ACCELQ's docs don't mention OData by name, so treat these services as REST with JSON responses. The same API Policy check from lesson 2 applies to anything an agent calls directly.

CI: the REST trigger and CI Jobs

In ACCELQ, you create a CI Job from the Run modal (When to Run, then Create a CI Job) and copy its job ID. A pipeline then starts it with a REST call: a PUT to https://{server}/awb/api/{tenant code}/{project code}/v1/api_access/jobs/trigger-job with user_id and api_key headers, and a JSON body holding the jobPid and optional runProperties. The response lists the runtime job IDs that started, and a separate API reports a job's status. A Jenkins plugin and articles for other CI tools exist too. Claude Code can write this pipeline step; the API key lives in the CI secret store, never in the prompt.

A later pipeline stage can run Claude Code headless to summarize results: claude -p with --output-format json, a narrow --allowedTools list and --permission-mode dontAsk, which denies anything not pre-approved. Anthropic recommends --bare for scripted runs so the job doesn't pick up hooks or settings from the runner's home directory. Bare mode also skips CLAUDE.md and MCP servers, so pass the rules the job needs explicitly, for example with --append-system-prompt-file and --settings. For unattended jobs, --permission-prompts none (recent Claude Code versions) denies anything that would wait for a person instead of letting the run hang; check the CLI reference for your version.

The platform runs and records the tests; Claude Code summarizes a masked export; Priya decides what becomes a defect.

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

Guardrails

DataNo production data; masked exports only; commercial terms, and zero data retention where eligible.

AccessNo CMP hosts; deny rules and a PreToolUse hook on production names; sandboxing or a container.

SecretsAPI keys and passwords in the CI secret store or encrypted platform parameters, never in prompts or CLAUDE.md.

InputTreat pages, logs and report text as untrusted; no autonomous actions on what they say.

ReviewEvery AI-drafted Scenario, data set or script has a named human reviewer before it runs for the record.

TraceabilityLabel AI-assisted assets; record the tool and model used; keep evidence in the platform and SAP Cloud ALM.

Six layers of guardrails for using Claude Code around an SAP test platform.

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

Hands-on lab · ACCELQ

Trigger an ACCELQ CI Job from a script

A CI Job lets a pipeline start ACCELQ runs. Here you create one and trigger it with the REST endpoint; you can ask Claude Code to draft the script, but keep the key out of the prompt.

Practice on Your lab Scenario from lesson 5 on the SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first.
Open your cart Scenario and click Run. Under When to Run, choose Create a CI Job, pick your Agent, click Create Job and copy the job ID from the confirmation.
In your User Profile, open Auth properties and note your tenant code, project code and API key. Store the key in an environment variable on your machine, not in a file.
Write a short script (or ask Claude Code to draft one, giving it only the variable names) that sends a PUT to the trigger-job endpoint with user_id, api_key and Content-Type: application/json headers and the body {"jobPid": "<your job ID>"}.
Run the script. It should print an array with the runtime job ID that started.
Open Results, find the run, and watch it move from Scheduled to finished on your Agent.
Check your shell history and the script file: the API key must not appear in either.

Done when The script starts the job, the Test Report shows a passing run, and no key appears in files, prompts or history. Keep the Test Report link and the script.

Learn more in ACCELQ’s docs: REST API end-point to trigger test execution externally · Running Automation Test

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

What would you do?

Theo wants to save a step: he plans to paste the ACCELQ API key into his Claude Code prompt and ask it to trigger the nightly job and analyze the results in one go. What should Priya advise?

Key points

Let the platform run and record tests; use Claude Code for drafting, analysis and pipeline glue.
Draft Scenarios that reuse existing Actions, and data rows with real boundaries.
Analyze masked exports, treat report text as untrusted, and let testers raise the defects.
Trigger CI Jobs with the REST endpoint from the pipeline; keep keys in the secret store.
Run Claude Code headless with narrow tools and dontAsk permissions in CI.

Drafting scenarios and data

Analyzing failures from reports

API checks

CI: the REST trigger and CI Jobs

Guardrails

Lesson check