PowerTesting Docs
Back to PowerTesting

User Guide

This guide walks through every screen in the PowerTesting UI — what each control does, where data comes from, and how to read what you see.

UI Layout

PowerTesting uses a sidebar + main-content layout, the same shape as PowerOrchestrator and PowerAdmin. There is no sign-in — the testing UI is open access.

The fixed sidebar on the left holds every navigable section, grouped under Monitoring:

TabIconPurpose
DashboardCross-product health and recent activity at a glance.
PowerSolverSolver-specific test cases and runs.
PowerForecastForecast cases — MAPE / RMSE / horizon checks.
PowerDecisionDMN evaluation cases.
PowerAILLM-output schema and latency cases.
PowerOrchestratorEnd-to-end pipeline runs.
HistoryEvery run ever recorded, newest first.
CoverageOrphan validators and orphan references.

The sticky top header shows the current page title on the left and the environment switcher on the right. The page title updates as you change tabs.

Environment Switcher

The dropdown in the top-right controls which environment every run targets. Switching environments rewrites every base URL the run controller will hit.

  • local — ports on localhost (developer machine).
  • prod — the deployed Hetzner cluster. A red PROD badge appears next to the dropdown so you can't miss it.

The choice is saved to localStorage and synced to the testing-api so it survives a cache clear. First-visit on a real domain defaults to prod; on localhost it defaults to local.

Heads up: the env switcher does not undo. If you accidentally fire a run against prod, that run is recorded in prod history.

Dashboard

The Dashboard is the default landing page and answers two questions:

  1. Is the platform healthy right now?
  2. What ran recently, and did it pass?

Product Health Cards

A grid of cards — one per product. Each card pings the product's health endpoint and shows status with colour:

StatusMeaning
UPHealth endpoint responded ok.
SLOWResponded, but above the latency threshold.
DOWNHealth endpoint returned non-2xx or timed out.
UNKNOWNNever probed (just opened the page) or CORS-blocked.

Auto-Refresh

A toggle on the dashboard re-probes every product every 30 seconds. Turn it off when you're not actively watching — it saves the products from the constant ping load.

Recent Runs

Below the health grid is a compact table of the last ~10 runs across all products. Each row shows product, environment, started-at, duration, pass/fail counts, and a link to the run detail. Click the row to drill in.

Product Tabs

Each product gets its own tab. The layout is the same across all five so once you learn one you know them all.

Case List & Filters

The left side of the panel lists every test case for that product. Filter controls at the top let you narrow by:

  • Level — L1 only, L2 only, or both.
  • Tagregression, smoke, custom tags from the case JSON.
  • Text search — matches case id and description.

Each row has a checkbox. The toolbar at the top of the list includes Select all, Clear, and an indicator of how many are selected.

Run Panel

Once you've selected at least one case, click Run selected. A progress panel appears showing the current case, the running total, and a cancel button. Cancel aborts in-flight cases via AbortController; finished cases are still recorded.

Results Table

When the run finishes, the right side of the panel shows a results table:

ColumnMeaning
CaseTest case id; click to expand the captured response and validator details.
Statuspassed / failed / error / cancelled pill.
DurationWall-clock time from submit to validator exit.
ValidatorsOne pill per validator, green for ok, red for not-ok. Hover for the message.
TraceIf the product emitted a trace, expand to see stage-level timings.

History

History lists every run ever recorded across all products and environments. Filter by product, environment, status, and time window. Each row is clickable.

Run Detail

Clicking a run in History (or the dashboard) opens the run detail view. This is the same results table you see right after running, but loaded from history rather than memory. URL-shareable: copy the link and another developer can open exactly that run.

Diff View

From any run detail, the Diff against... picker lets you compare against an earlier run (typically the same product, previous run). The diff view lays out cases by bucket: regressions first (red), then fixes (green), then newFailures, newPasses, removed, stableFail, and stablePass.

Workflow tip: after every deploy, diff the first post-deploy run against the last pre-deploy run. The regressions bucket is your shipping blocker.

Coverage

The Coverage tab shows, per product:

  • Orphan validators — registered but unused. Either delete the validator or write a case that uses it.
  • Orphan references — named in a case but not registered. Will fail at runtime.
  • Coverage scopes — how many cases cover each generic validator (status / field-match / schema / response-time) per product.

The platform-wide summary at the top shows total registered, total referenced, and the delta. Aim for zero orphans on both sides.

Status Reference

One table to anchor every status pill you'll see in the UI:

PillWhereMeaning
UP / PASSHealth card / results tableHealthy / validators all ok.
SLOWHealth cardResponded but above latency threshold.
DOWN / FAILHealth card / results tableNot reachable / at least one validator failed.
UNKNOWNHealth cardNever probed yet, or CORS-blocked.
ERRORResults tableAdapter / network exception — no validator ran.
CANCELLEDResults tableYou hit cancel mid-run.

Keyboard & Tips

  • Click a sidebar item — switches tabs without a full page reload.
  • Click a recent-run row — jumps straight to the run detail.
  • Click a results row — expands to show captured response & validator messages.
  • Hover a validator pill — reveals the validator's message without clicking.
  • Browser refresh — safe; the env preference and last tab are persisted.