Sap Sac Test Automation

SAP Analytics Cloud Test Automation

Design reusable SAC test automation as a capability-gated system: select the safest available discovery backend, require human review for profiles and baselines, then use reviewed Playwright code for deterministic execution, CI gating, reporting, and evidence.

Apply the core rule: discovery proposes, humans approve, Playwright executes, CI enforces.

Related Skills

• sap-sac-scripting: Use for Optimized Story Experience scripting, Analytics Designer APIs, diagnostic widgets, story script behavior, and SAC MCP setup.
• sap-sac-planning: Use for planning models, private/public versions, data actions, multi actions, validation rules, and writeback risk analysis.
• sap-sac-custom-widget: Use when dashboards include owned custom widgets that need stable ARIA labels, public test hooks, lifecycle fixes, or black-box test contracts.
• sap-dependency-security: Use before adding source-pinned browser tools, MCP servers, CI dependencies, or executable automation that handles SAC credentials.
• sap-browser-automation: Use for in-app manual authentication, consent-gated Edge profile reuse, fresh Edge/CDP startup, auth-state bootstrap, and browser recovery.
• agent-browser: Optionally load when the Vercel Labs agent-browser CLI is available and exact command syntax, snapshot/ref usage, screenshots, console, or network inspection is needed.
• playwright: Optionally load for CLI-based browser driving and debugging. For durable @playwright/test suites, use this SAC skill as the test architecture guide and follow the local project's Playwright conventions.
• chrome-devtools: Optionally load when Chrome DevTools MCP is installed and approved for read-only browser discovery, console/network inspection, screenshots, Lighthouse, or performance traces. An explicit Chrome, Edge, CDP, or Chrome DevTools MCP request is binding. Use references/chrome-devtools-mcp.md for SAC-safe defaults and Edge boundaries.

Initial Guidance

When the user is starting SAC automation or has not supplied a reviewed dashboard profile, route them through /sac-test-onboard or follow the same intake sequence manually. Use a two-stage intake:

• Stage 1: environment class, tenant risk, allowed discovery/execution tools, auth and roles, writeback/comment scope, and baseline ownership.
• Stage 2: planning/writeback, comments, permissions, visual/data baselines, custom widgets, CI stages, and failure evidence.

Default to draft-only artifacts until the user explicitly confirms file creation and target directory. If writing is confirmed, use profiles/<profile-id>/intake.md, profiles/<profile-id>/dashboard.yaml, and profiles/<profile-id>/scenarios/read-only-smoke.yaml based on the bundled templates.

After a profile or scenario draft exists, route safety review to sac-test-profile-reviewer when available. Keep the reviewer focused on intake/profile/scenario safety, not broad Playwright suite implementation.

When to Use This Skill

Use this skill to plan, implement, or review SAC automation involving:

• SAC stories, optimized stories, reports, dashboards, tabs, filters, prompts, tables, charts, exports, scripts, comments, or bookmarks.
• Dashboard profile files, scenario YAML, expected data files, visual baselines, Playwright adapters, and SAC-specific fixtures.
• Stored authentication state, SSO/MFA constraints, role-based test users, permission matrices, and CI gates.
• Planning writeback, private/public versions, data locks, validation rules, data actions, multi actions, or comment cleanup.
• Failure packets with traces, screenshots, videos, visual diffs, expected-vs-actual values, console/network summaries, and root-cause classification.

Do not use this skill as the main guide for generic web applications. Use general Playwright guidance for non-SAC sites.

Quick Start

1. Classify the SAC story: production read-only, QA clone, planning/writeback, comments, permission-sensitive, or exploratory.
2. Establish the automation policy: allowed tenants, allowed users, auth storage handling, writeback approval, baseline approval, and CI triggers.
3. Run the capability and policy gate. If the user named a browser or connection method, check only that requested surface. Otherwise choose manual discovery, Firecrawl public research, Chrome DevTools MCP with supported Chrome, Microsoft Edge/CDP, Chrome DevTools MCP with Edge best-effort, Playwright, agent-browser, or an approved enterprise browser lab based on what is installed and allowed.
4. Run read-only discovery with the selected backend: capture snapshots, annotated screenshots, console/page errors, network clues, and candidate component maps without sending private SAC content to unapproved external services.
5. Convert discovery into a human-reviewed dashboard profile: pages, widgets, locators, readiness markers, roles, data baselines, visual baselines, and known restrictions.
6. Implement deterministic Playwright tests through reusable adapters. Keep scenario files selector-free; route interactions through component IDs from the profile.
7. Gate only safe packs in CI first: auth check, read-only smoke, navigation, and critical widget readiness. Move planning, comments, data actions, visual baselines, and full permissions to controlled/nightly stages.
8. Emit reviewer-friendly failure evidence: HTML report, trace, screenshots, video, visual diff, widget metadata, expected vs actual values, and failure category.

Read-Only Story Acceptance

Apply this contract to reporting-only SAC stories and dashboards. It complements the profile-driven smoke scenario and does not authorize planning or model changes.

Tenant and Model Safety

• Confirm the approved tenant, story, and data source/model before interaction.
• Verify that the current SAC area is Story Designer, not Modeler.
• Confirm that no model edit dialog, model save, master-data change, permission change, planning writeback, version publish, data action, multi action, or lock change occurred.
• Bind assertions only to dimensions, measures, hierarchies, filters, and comparison categories exposed by the approved model. If a required field is unavailable, omit the dependent widget and record the omission.

Story Readiness

• Open each page and wait for page-specific readiness markers, spinner disappearance, stable widget state, and the absence of visible SAC error messages.
• Verify that every KPI, chart, and table displays values or an explicit no-data state; loading completion alone is not sufficient.
• Confirm that filters populate, accept valid values, and update dependent widgets without changing the model.
• Exercise approved selections, navigation, and drilldowns where configured; verify that the resulting table or chart state is consistent.
• Record unresolved widgets, invalid bindings, unavailable fields, relevant console or network errors, and tenant-specific limitations.

Evidence

• Capture an approved screenshot or equivalent artifact for each story page and retain the story name and location.
• Pair visual evidence with KPI, table, or data assertions; do not use chart pixels as the only business-value check.
• Redact tenant identifiers, story IDs, session-like URL parameters, credentials, cookies, private screenshots, and unrelated tab content.

Browser Failure and Honest Handoff

Browser access is an execution prerequisite, not evidence that the story exists. If browser initialization or discovery fails, including runtime errors such as agent is not defined:

1. Read the selected browser troubleshooting guidance and retry discovery without bypassing authentication or tenant permissions.
2. If the user explicitly named a browser or connection method, do not switch to another browser surface. If its tools are not in the active registry, ask for a Codex restart or a new task.