/sap-sac-test-automation

name: sap-sac-test-automation
description: |
  SAP Analytics Cloud (SAC) automated testing skill for designing capability-gated browser discovery and deterministic Playwright test suites for SAC stories, dashboards, reports, planning workflows, comments, permissions, visual regression, and reusable QA automation. This skill should be used when building SAC end-to-end tests, onboarding SAC dashboards into Playwright, creating dashboard profiles or scenario YAML, using Microsoft Edge/CDP, Chrome DevTools MCP, Vercel Labs agent-browser, or manual discovery for SAC components, testing SAC optimized stories, configuring SAC auth storage state, managing visual/data baselines, testing comments, planning writeback, data actions, multi actions, role-based views, restricted Windows/company environments, or creating SAC failure triage artifacts.
license: GPL-3.0
metadata:
  maintainer: "Eduard Jiglau"
  maintainer_email: "hello@sap-ai-skills.com"
  website: "https://sap-ai-skills.com"
  version: "2.4.1"
  last_verified: 2026-06-17
  sac_version: "2026.8"
  documentation_source: "docs/project/sac-test-automation-source-review-2026-06-17.md"
  primary_tools:
    - Playwright
    - Chrome DevTools MCP
    - Microsoft Edge CDP
    - Vercel Labs agent-browser
    - Manual discovery
  status: docs_audited_runtime_pending
  known_issues:
    - Live SAC tenant, SSO, planning writeback, and CI execution checks require tenant-specific evidence before claiming runtime validation.

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 enter