SAAS RELEASE TEST PLAN
Original fictional exercise and blank template. Checked October 28, 2026.

COMPLETED PLANNING EXAMPLE
Project: BriefRelay client intake, release candidate RC-7.
Purpose: decide whether the bounded intake release has enough verification evidence for a pilot.
This is an invented plan. Every test below is NOT RUN. No software release or customer research is represented.

Scope: permitted client submits a brief, receives a reference, and can retrieve its own receipt. Support can inspect status without opening private files.
Excluded: production payment processing, a new identity provider, broad penetration testing, load beyond the stated pilot, and unrelated editor changes.
Requirements: AC-1 required title is validated; AC-2 receipt belongs to the authorized workspace; AC-3 retry does not create a second logical submission; AC-4 failed upload has a usable recovery path.
Risk focus: accidental cross-workspace receipt access, repeated submissions, lost confirmation, and unsupported file types.
Candidate identity: RC-7, exact commit/build identifier to be recorded by the team.
Environment: isolated staging workspace Alpha and Beta, synthetic user accounts and invented files. Record browser, app configuration, schema and dependency versions before execution.
Data: one valid brief, one missing title, one rejected file type, a replay request, and an unauthorized receipt ID. No real customer files.
People: Engineering prepares the candidate and automation; Support exercises recovery; Product reviews expected behavior; the named release owner makes the pilot decision.
Entry criteria: candidate identifier recorded, environments available, synthetic data reset, access boundaries agreed, and expected results reviewed.
Execution: run the high-risk permission and duplicate cases first, then ordinary submission and recovery. Record actual output, evidence reference and defect link for every case.
Exit criteria for this exercise: all named cases executed against the recorded candidate; expected permission boundaries hold; failures are resolved and retested or explicitly recorded as an unresolved release decision. Do not silently count blocked or unexecuted cases as passes.
Pause conditions: environment identity uncertain, unexpected customer data, invalid permission boundary, or an issue preventing reliable observation.
Evidence: use the companion CSV. Keep sensitive logs in approved storage and share a reference instead of raw contents.
Decision: NOT MADE. Candidate, evidence, unresolved risks, decision owner and date must be supplied.
Change trigger: any change to upload handling, identity scoping or receipt creation requires review of affected cases and relevant regression work.

BLANK PLAN
Plan ID and owner:
Bounded product change:
Candidate build/commit:
Decision this evidence supports:
Included workflows:
Excluded workflows and reasons:
Requirements and risk references:
Environment, configuration and browser versions:
Synthetic data and reset procedure:
Test responsibilities and backup owners:
Entry criteria:
Cases and expected results:
Execution order and schedule:
Pause/resume conditions:
Evidence location and access:
Defect handling, retest and regression scope:
Exit criteria:
Executed / passed / failed / blocked / not-run counts:
Unresolved findings:
Release decision, owner and date:
What changes require another review:

Use precise status labels. A template, planned case, or test count alone does not establish release readiness.