Alpha v1 UAT — Readiness Report

Updated: 2026-08-02 06:54 ET · Sprint 2026-07 Tester Readiness (22–31 Jul) · Next: 2026-08 August Sprint (3–28 Aug) · UAT Hardening from 31 Aug

We entered the testing phase on target.

The 2026-07 Tester Readiness sprint closed on schedule (31 July) with the tester launch point, the walkthrough set and the surfaces behind them in place. Alpha v1 UAT can start. Two caveats below are worth reading before it does — one about what testers will hit, one about what the board says versus what shipped.

1 · Sprint delivery against target

Sprint	Window	Committed	Closed	Outcome
2026-07 Tester Readiness	22–31 Jul	11 items	4 closed	Phase entered on target
2026-08 August Sprint	3–28 Aug	—	—	Runs alongside UAT
2026-09 UAT Hardening	31 Aug – 25 Sep	—	—	Planned

The board understates what was delivered. Of the seven items still showing New, at least two are done in the product: AB#2322 (graduate Notifications + Notification Settings to To Test) and AB#2323 (graduate KCM to To Test). Both surfaces are on the To Test launchpad today, both are walkthrough-documented, both were validated live. The work item states have not caught up with the merges.

Read the 4-of-11 figure as bookkeeping, not as delivery. Before anyone reports on sprint burn-down, those states need reconciling against what actually merged — deliberately not done here, since closing someone else's work items is a call for the team, not for this document.

What landed for testing readiness

Tester launch point (Page Readiness → To Test) covering Login, Profile, Page Banner, Favorites, Home Preview, KCM, Flight Finder, FTDT and Notifications.
Seven tester walkthroughs, all screenshot-backed: login/logout, promo banner, favorites, KCM, Flight Finder, FTDT, notifications.
Flight Finder notifications wired to their real service, with push deep-links landing on the alert that was tapped.
Two scenario launchers for states that cannot be reached by ordinary use — push/deep-link, and every empty state in one place.
A data-source and FTDT sync panel on the readiness board, so a tester can tell real data from a stand-in.

2 · Per-surface readiness

Surface	Built	Walkthrough	Validated live	Data source
Login / Logout	yes	yes	yes	Live auth
Profile	yes	partial — logout only	yes	Live, needs login
Promo banner	yes	yes	yes	Mock (labelled)
Favorites	yes	yes	yes	Mock — gateway rollout pending (AB#2237)
KCM (5 screens)	yes	yes	yes	Live
Flight Finder search / results	yes	yes	yes	Live, needs login
Notifications — Comms	yes	yes	yes	Live
Notifications — Flight Finder	yes	yes	yes	Live; sample flight when you have no subscriptions
Notification Settings	yes	covered in notes	signed-out defect	Live, needs login
FTDT	yes	yes	yes	Tester-selectable — mock or live
Documents / Internal Comms	yes	none	partial	Live signed in, mock signed out
Member Resources	yes	none	partial	Mock menu
My MEC (5 screens)	built	none	no	Blocked on theme endpoint (AB#2185–2187)

Data sources are also shown live in the app — Page Readiness → All → Data sources — derived from the pinned values rather than restated, so the app is the authority if these disagree.

3 · FTDT sync

FTDT is the one area where a tester picks the data source, on the FTDT dashboard. The readiness board shows the current selection, last sync time, duty periods held and how many sit in a sync-error state.

Seeded scenario data must never reach a production account (AB#2342, AB#2356). If you are signed in as a real member and see duty periods you did not create, stop and report it. This is the one FTDT failure that matters more than any calculation bug.

4 · Known defects testers will hit

What you'll see	Where	Item
An error banner on opening Notification Settings while signed out	Notification Settings	AB#2375 — no ErrorBoundary anywhere; the subscriptions call needs a login and its 401 is unhandled
Blazor Dev tile present on first launch, absent afterwards	Native home	AB#2304
Signed out after relaunching the app	Anywhere authenticated	AB#2305
My MEC screens unbranded / incomplete	My MEC	AB#2185–2187 — theme endpoint not delivered

Please don't re-report these. Anything else is worth raising.

5 · Open design asks

None block UAT; all are live and testable as-is, and testers should comment on how they read rather than on whether they match Figma.

Flight Finder notification grouping — Figma only ever drew a single flight-status card, never a list of them. Four layouts proposed, seven questions open.
Empty state inventory — "empty" is currently expressed three different ways, and eleven surfaces have no empty state at all. The four My MEC screens and search results matter most.
Expand/collapse consistency — accordion in some places, multi-open in others, and expansion survives navigation only in Flight Finder results. Both behaviours are defensible; the divergence is what needs a decision.

6 · Entry and exit criteria

Entry (met): tester launch point live; walkthroughs published for every To Test surface except Profile and Documents; data sources visible in-app; known defects listed above.

Exit: every walkthrough run once per platform; no new P0/P1 open; the two graduation work items reconciled; design responses received on the two asks above.

7 · Reporting a finding

Say which walkthrough and check number you were on — that is what makes a report reproducible.
Say which tab or screen, and whether you were signed in. Several surfaces behave differently either side of a login.
For flight alerts, say whether the sample-flight note was showing — it decides whether you were looking at your own data.
Screenshots help more than descriptions for anything visual.