Skip to content

Migrate Actionable Observability-owned FTR suites to Scout #263519

@shahzad31

Description

@shahzad31

Summary

Track migration of Functional Test Runner (FTR) suites that are owned by @elastic/actionable-obs-team (per .github/CODEOWNERS) to Scout (Playwright-based), so we reduce FTR maintenance cost and align with the platform direction for new functional/API tests.

This issue is meant as a parent epic; consider splitting work into smaller issues or PRs per area (e.g. uptime/synthetics vs observability API integration vs alerting).


Progress

Merged

In progress (open draft PRs)


Scope: FTR configs to migrate

These paths are listed in observability FTR manifests (.buildkite/ftr_oblt_stateful_configs.yml / .buildkite/ftr_oblt_serverless_configs.yml) and fall under CODEOWNERS rules for @elastic/actionable-obs-team. Test counts are approximate (it(...) occurrences in test files at the time of writing).

Stateful (ftr_oblt_stateful_configs.yml)

Serverless (ftr_oblt_serverless_configs.yml)

Related (CODEOWNERS: actionable obs; not a standalone FTR entry in the manifests)

  • src/platform/test/api_integration/apis/suggestions — ~12 tests; owned by actionable obs; confirm whether tests are only pulled in via broader API integration configs and migrate coverage accordingly.

Guidance for Scout migration

1. Decide the right layer (avoid “FTR parity” for its own sake)

  • Prefer unit / RTL for isolated UI logic; Scout API tests for data correctness; Scout UI tests for real user journeys and rendering/interaction.
  • If a test mostly asserts API payloads or document counts, migrate it to a Scout API spec (or keep/ add server-side tests), not a browser spec.
  • See: docs/extend/scout — start with Getting started, Best practices, Write API tests, Write UI tests.

2. Scaffold and location

  • Add Scout tests under the owning plugin/package test/scout/ tree (see existing examples in observability plugins, e.g. observability, slo, infra).
  • Follow Setup Plugin for scout config in kibana.jsonc and Playwright wiring.

3. FTR → Scout mapping

4. Running tests locally

From repo root (see Run tests):

node scripts/scout.js run-tests --stateful --config <path-to-scout-config>
# or --testFiles for specific specs

5. AI-assisted migration (optional)

  • Experimental prompts and notes for FTR→Scout migration live under src/platform/packages/private/kbn-scout-info/llms/ — treat output as review-required, not copy-paste.

6. CI / ownership

  • After migration, remove or narrow FTR config usage and update CI/manifests as required by the Appex QA / build pipeline expectations for Scout.
  • Coordinate with @elastic/observability-ui and other teams where CODEOWNERS overlap (many observability FTR paths are shared across teams).

Definition of done (per area)

  • Equivalent coverage exists under Scout (or explicitly justified as moved to API/unit tests).
  • FTR config(s) for that area removed or disabled with a clear follow-up if anything is deferred.
  • Documentation or README updated if the plugin has a test/scout/README.md pattern.

References

Metadata

Metadata

Assignees

Labels

Team:actionable-obsFormerly "obs-ux-management", responsible for SLO, o11y alerting, significant events, & synthetics.

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions