Internal Live Create

Content -> Internal Live Create - QA Test Plan

Pre-release checklist for Internal Live Create. This flow publishes live channels; a bad configuration can fail a stream launch or send viewers to the wrong destination.

Totals

Coverage summary (Critical + High)

• 9 (Critical: 7, High: 2)
• 13 (Critical: 4, High: 9)
• 2 (Critical: 1, High: 1)

Automation anchors

• awsPayload.test.ts
• harmonicPayload.test.ts

These automated suites cover payload-level validation and guard rails. Manual QA should focus on UI flow, service errors, and end-to-end launch confidence.

Validation behavior note: this flow mixes schema-level validation (for core required selectors) with submit-time payload validation. Some invalid combinations surface as submit errors/toasts rather than field-level inline errors.

Critical - Release blockers

C1 - Required launch fields block empty submit

Scope: Channel creation cannot proceed when required fields are missing.

Steps:

1. Open Internal Live Create and leave required fields empty.
2. Click Create/Save.

Expected: Validation feedback appears and no create request is sent.

Risk: Empty or malformed channels get created and fail at launch.

C2 - Destination endpoint validation rejects invalid targets

Scope: Destination URL/IP/port combinations must be valid for selected protocol.

Steps:

1. Select each supported protocol one by one.
2. Enter invalid destination values (bad host, bad port, malformed URL/IP).
3. Submit.

Expected: Validation blocks submit with clear guidance (inline and/or submit error feedback depending on provider/path).

Risk: Streams are created but cannot connect to source or destination.

C3 - Protocol-auth mismatch is blocked

Scope: Authentication fields must match protocol mode; partial auth is rejected.

Steps:

1. Select a mode that requires auth.
2. Fill only part of the auth inputs.
3. Submit.

Expected: Submit remains blocked until auth values are complete.

Current gap: partial auth values can be silently dropped in submit payload composition instead of being blocked pre-submit.

Risk: Ingest fails on first connection attempt.

C4 - Backup path requires complete secondary configuration

Scope: Enabling backup/secondary output requires all dependent fields.

Steps:

1. Enable backup or secondary path.
2. Fill only some secondary fields.
3. Submit.

Expected: Submit is blocked until secondary configuration is complete.

Risk: Failover is assumed to exist but does not work during outage.

C5 - Caption selector requires complete caption setup

Scope: Caption settings must be complete when caption selector is enabled.

Steps:

1. Enable caption selector.
2. Leave one required caption field blank.
3. Submit.

Expected: Validation prevents submit with a clear caption error.

Risk: Captions silently fail in production.

C6 - Ad insertion dependencies are enforced

Scope: Ad insertion settings require all linked fields when enabled.

Steps:

1. Enable ad insertion.
2. Leave required ad fields incomplete.
3. Submit, then complete the fields and submit again.

Expected: Incomplete config is blocked; complete config is accepted.

Gap note: AWS dependency checks are stronger than Harmonic MediaTailor gating in current form wiring.

Risk: Monetization path fails or ad breaks misfire.

C7 - Invalid schedule windows are blocked before submit

Scope: Harmonic LIVE_EVENT schedule windows must reject invalid ranges, including past times and too-short windows.

Steps:

1. Set end time before start time.
2. Submit.
3. Correct schedule and resubmit.

Expected: Invalid window is blocked; corrected window is accepted.

Risk: Channel launches outside intended window.

C8 - Protocol-specific required identifiers are enforced before create

Scope: Required protocol identifiers (for example stream keys or primary flow entitlement) must be present.

Steps:

1. Select RTMP push mode and leave one stream-key field blank.
2. Submit and confirm it is blocked.
3. Select MediaConnect flow mode without primary flow entitlement.
4. Submit again.

Expected: Submit is blocked in both cases with clear guidance on missing required identifiers.

Risk: Channel is created with incomplete ingest identity and fails immediately at runtime.

C9 - Harmonic cluster prerequisites cannot be bypassed

Scope: Harmonic region, protocol, and backup region prerequisites must be valid before create.

Steps:

1. Select Harmonic mode.
2. Attempt create with missing region or missing protocol.
3. Enable secondary service without backup region and submit.

Expected: Create is blocked until all required cluster prerequisites are provided.

Risk: Service provisioning fails before stream startup.

C10 - Existing input and source mapping completeness is enforced

Scope: When using existing inputs or sources, required primary and backup selections must be complete.

Steps:

1. Enable "use existing input/source" options.
2. Leave one required main or backup selection empty.
3. Submit.

Expected: Create is blocked with targeted missing-selection errors.

Risk: Channel routes to an incomplete topology and never reaches stable ingest.

C11 - SRT Caller transport guardrails are enforced

Scope: SRT Caller requires valid primary endpoint values and valid decryption key shape when provided.

Steps:

1. Select SRT Caller.
2. Submit without primary IP or primary port.
3. Enter a short decryption key and submit.

Expected: Submit is blocked until endpoint and key validations pass.

Risk: Secure ingest cannot be established.

C12 - Scheduling and DVR mandatory fields are enforced

Scope: Harmonic scheduling start time and DVR start-over values must be present when those features are enabled.

Steps:

1. Enable scheduled service and clear start time.
2. Enable DVR and leave start-over time blank.
3. Submit.

Expected: Harmonic create is blocked until required scheduling and DVR fields are complete.

Risk: Stream timing behavior becomes invalid or non-operational.

High - Core flows

H1 - AWS happy path creates a valid channel

Scope: Basic AWS launch path should be reliable end-to-end.

Steps:

1. Fill a minimal valid AWS configuration.
2. Submit and verify success state.

Expected: Channel is created and visible with expected key details.

Risk: Correct user inputs still fail launch.

H2 - Harmonic happy path creates a valid channel

Scope: Basic Harmonic launch path should be reliable end-to-end.

Steps:

1. Fill a minimal valid Harmonic configuration.
2. Submit and verify success state.

Expected: Channel is created and visible with expected key details.

Risk: Core launch flow breaks for Harmonic operators.

H3 - Slate toggle includes and excludes slate fields correctly

Scope: Slate-related payload fields should only be sent when slate settings are enabled for the active provider path.

Steps:

1. Enable slate and save valid values.
2. Disable slate and save again.

Expected: Slate settings are included only when enabled and excluded after disable/reset.

Risk: Stale slate values leak into live payload.

H4 - Harmonic secondary source validation is enforced

Scope: Secondary source configuration requires valid combinations.

Steps:

1. Enable secondary source.
2. Provide incomplete source details.
3. Submit.

Expected: Submit is blocked until secondary details are valid.

Risk: Failover source fails during incident.

H5 - Service failures show actionable error feedback

Scope: Backend/API failures should surface clear next actions.

Steps:

1. Trigger a known create failure.
2. Observe error message and retry guidance.

Expected: Error messaging identifies the failure clearly and supports a clean retry path.

Gap note: current flow mainly surfaces toast-level errors and lacks richer inline recovery guidance.

Risk: Operators lose time during launch windows.

H6 - Mode switches do not retain incompatible stale values

Scope: Switching protocol/provider clears incompatible inputs.

Steps:

1. Fill advanced fields for one mode.
2. Switch to another mode.
3. Submit valid minimal values for the new mode.

Expected: Stale incompatible values do not leak into submission.

Risk: Hidden stale values cause non-obvious failures.

H8 - Boundary-time scheduling remains stable across timezone changes

Scope: Near-midnight and DST boundary schedules should stay accurate.

Steps:

1. Create schedule near day boundary.
2. Refresh and verify displayed and persisted times.

Expected: No off-by-one-hour or off-by-one-day drift.

Risk: Events go live at the wrong time.

H9 - AWS low-latency mode follows the fixed ingest path

Scope: Enabling low-latency mode should enforce the intended AWS ingest behavior without conflicting protocol state.

Steps:

1. Enable low-latency mode for AWS.
2. Complete the minimum required ingest fields.
3. Submit and verify successful create payload shape.

Expected: Low-latency create succeeds and uses the expected fixed ingest path.

Risk: Operator-selected latency mode yields incompatible ingest configuration.

H10 - Harmonic linear-channel mode toggles dependent sections correctly

Scope: Harmonic service type (LIVE vs LIVE_EVENT) should show/hide dependent schedule/live-to-VOD inputs consistently.

Steps:

1. Toggle Use for Linear Channel on/off.
2. Observe schedule and related section visibility changes.
3. Submit valid inputs in each mode.

Expected: Dependent sections and validation expectations track the selected service type.

Risk: Hidden/visible section mismatch causes invalid submissions.

H11 - Harmonic permission gates enforce disabled capabilities

Scope: Capability-restricted options (SSAI, DRM, DVR, backup, linear mode) should remain disabled and excluded when permissions do not allow them.

Steps:

1. Open Harmonic create with restricted-capability context.
2. Verify restricted toggles are disabled or unavailable.
3. Submit and inspect resulting payload behavior.

Expected: Restricted capabilities cannot be enabled through normal UI interaction.

Risk: Unauthorized feature flags leak into create payloads.

H12 - Slate and SSAI coupling remains payload-safe

Scope: Slate and SSAI dependencies should remain synchronized when toggles are enabled/disabled in different orders.

Steps:

1. Enable slate and verify SSAI dependency behavior.
2. Disable SSAI and verify slate dependency behavior.
3. Submit and inspect resulting payload.

Expected: Toggle coupling does not leave conflicting slate/SSAI state in payload.

Risk: Ad/slate behavior is internally inconsistent at stream start.

H13 - Macros and automation settings serialize correctly

Scope: Manual/query-param macros and automation settings should persist with expected payload shape.

Steps:

1. Configure macros in both supported entry modes.
2. Configure automation/runtime controls where available.
3. Submit and verify persisted behavior.

Expected: Macro/automation values are serialized without shape loss or mode crossover.

Risk: Automation or macro behavior diverges from operator intent in production.

Medium - Edge cases and UX gaps

M2 - Long text input limits behave predictably

Scope: Name and metadata limits should be enforced clearly.

Steps: Submit max-length and over-limit values.

Risk: Late-stage rejection or silent truncation surprises users.

M3 - Optional fields do not become required after toggles

Scope: Advanced toggle changes should not force unrelated optional fields.

Steps: Toggle advanced options on and off, then submit minimal valid config.

Risk: Users get stuck in inconsistent validation states.

M4 - Unsaved-change warning appears on navigation

Scope: Prevent accidental loss of large in-progress forms.

Steps: Edit multiple fields and navigate away without saving.

Risk: Re-entry delays during urgent stream setup.

M5 - Keyboard-only flow works across critical controls

Scope: Form should be fully operable without a mouse.

Steps: Complete core create flow using keyboard only.

Risk: Accessibility and speed-to-operation gaps.

M6 - Refresh after validation error preserves entered values

Scope: Common retry patterns should not wipe non-sensitive inputs.

Steps: Trigger validation error, refresh, and verify retained state.

Risk: Repetitive data entry during high-pressure launches.

M7 - Field hints reduce first-time operator mistakes

Scope: High-risk fields need concise practical guidance.

Steps: Perform first-time operator walkthrough and note unclear fields.

Risk: Preventable setup mistakes increase support load.

M8 - Optional AWS preview/clean URL settings remain stable

Scope: Optional AWS playback-side toggles should not produce inconsistent defaults or accidental payload drift.

Steps: Toggle preview and clean URL related options across provider/mode changes, then submit minimal valid config.

Risk: Optional playback settings become unpredictable across setup retries.

Low - Polish and cleanup

L1 - Success and error messaging is consistent

Scope: Messaging should be brief, clear, and consistent.

L2 - Loading states are visible during create/update

Scope: Prevent duplicate submits and user uncertainty.

L3 - Empty/default states guide next action

Scope: Empty panels should give useful next steps.

L4 - Standard flow produces no noisy console warnings

Scope: Baseline create flows should be console-clean.

Out of scope

Third-party HLS create specifics and post-create Live Stream detail control-surface operations are tracked in Content Type QA - Live. Encoder infrastructure behavior, downstream playback certification, and partner-side ingest verification are also tracked outside this deep-create checklist.

Retired items

• M1 - Duplicate name conflict flow is clear (retired: internal create flow has no title/name field; duplicate-title behavior belongs to third-party create).