SAP Analytics Cloud 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.