analyze-and-plan

Analyze & Plan — Phase 1 (of 7)

The SAP UI testing workflow is split into seven standalone phases so no single step is rushed:

1. analyze-and-plan (this skill) — read the source → _flow.md + _units.md + _findings.md.
2. explore-ui — explore the live WebGUI in a browser → _screens.md.
3. design-cases — write one TC-XXX.md per candidate case, reviewed and indexed.
4. define-data — write each TC-XXX.data.md requirement spec.
5. prepare-data — resolve those specs into per-system data.json caches.
6. build-scripts — write one TC-XXX.spec.ts per runnable case.
7. run-scripts — execute, verify, and produce evidence.

This phase produces THREE reference artifacts under tests/<PROGRAM>/test-cases/: _flow.md, _units.md, and _findings.md. Together they are the full picture of the object that Phase 3 (and the reviewer) rely on. This phase does not open a browser and does not create any TC-XXX.md, _screens.md, or .data.md.

For bounded, self-contained support work, use sap-task-helper with explicit inputs, allowed writes, and an output contract.

Non-negotiable execution gate

Every required step and artifact below is a downstream prerequisite. The abapfs_run_playwright_tests tool (Phase 7) and the phase gates in between reject work whose upstream analysis was skipped, stale, incomplete, or unverified.

Why three artifacts, not one summary

A single summarised _findings.md is lossy: it is tempting to write "Data validation blocks (27 total)" as one table row. That one row is useless to Phase 3 — you cannot write 27 test cases from it, and the 27th validation (the one with the bug) silently gets no coverage. So Phase 1 produces the WHOLE picture, split by purpose:

• _flow.md — functional flow (the "FS"). How the object actually runs end to end: entry events, the call tree in execution order, and the main scenarios. This is what lets a later phase understand why a branch matters and what sequence triggers a screen.
• _units.md — unit inventory (the "TS"). Every FORM / METHOD / FUNCTION MODULE / event block, with its EFFECTIVE inputs and outputs — including DB tables read (inputs) and written (outputs), not just formal parameters. This is what drives correct post-test verification (which effects a case must verify) and correct data prep (which tables hold valid values).
• _findings.md — the decision surface. Every MESSAGE, every branch, every AUTHORITY-CHECK as ITS OWN ROW (never collapsed into an "(N total)" bucket), plus the enumerated candidate cases and the numeric target minimum.