Production Test and Verification Plan Prompt

Public field comparison

Test and Verification Prompt

Production Test and Verification Plan Prompt

Create a verification plan that covers unit tests, manual checks, edge cases, logs, and deployment confidence.

Use Codex to build an evidence-backed, risk-based verification plan covering automated tests, manual checks, CI gates, observability, rollback readiness, and release confidence.

—

Useful for assessing whether a software change is ready to release, identifying verification gaps, and producing traceable tests, evidence requirements, CI controls, and rollback checks.

CI/CD Pipeline Review
Deployment Safety Checklist
Rollback Planning
Production Readiness Checks
Release Verification
Test And Verification

Risk-based verification planning for complex software changes
CI/CD gate and test-suite effectiveness review
Pre-release evidence reconciliation and readiness assessment
Deployment smoke-test and observability design
Rollback, migration, and recovery verification

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Change or release under test
Repository and relevant files
System and runtime context
Acceptance criteria
Test and deployment constraints
Available evidence
Authorized actions and environment
CI/CD and rollback context

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In Codex, replace every bracketed variable with the requested project information. Provide the repository or relevant files, change diff, acceptance criteria, runtime details, test commands, CI configuration, logs, prior results, deployment controls, and rollback documentation. State exactly which files and environments Codex may inspect and which commands it may run, then run the prompt.

Use this when you need a production-ready testing result in Codex & Coding, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

Before releasing a database-backed API change, provide Codex with the pull-request diff, affected service files, API contract, migration, existing tests, CI workflow, staging logs, acceptance criteria, authorized test commands, monitoring thresholds, and rollback procedure. The result should trace release risks to specific checks, distinguish proposed tests from executed results, expose CI or rollback gaps, and issue an evidence-backed readiness recommendation without approving or deploying the release.

Expert

Expert

Codex

Codex

testing

testing

codex
Codex & Coding
testing
verification
qa

codex
software-testing
verification
ci-cd
release readiness
quality-assurance
rollback-planning

Test and Verification Prompt | AMO.ng

Production Test and Verification Plan Prompt | AMO.ng

Create a verification plan that covers unit tests, manual checks, edge cases, logs, and deployment confidence.

Build an evidence-backed verification plan with test traceability, CI gates, execution records, observability checks, and rollback readiness.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Codex & Coding specialist using Codex. Your task is: [Goal or task].
+Build a risk-based test and verification plan for the following software change or release.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Inputs
+- Change or release under test: [Change or release under test]
+- Repository and relevant files: [Repository and relevant files]
+- System and runtime context: [System and runtime context]
+- Acceptance criteria: [Acceptance criteria]
+- Test and deployment constraints: [Test and deployment constraints]
+- Available evidence: [Available evidence]
+- Authorized actions and environment: [Authorized actions and environment]
+- CI/CD and rollback context: [CI/CD and rollback context]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Test and Verification Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Codex operating boundaries
+- Use Codex to inspect supplied repository content, diffs, configuration, test suites, CI definitions, logs, and command output that are actually available in the session.
+- Run tests or read additional files only when the environment provides that capability and the authorized-actions input permits it. Prefer targeted, read-only inspection before expensive or state-changing commands.
+- Do not deploy, merge, approve a release, alter production, access undeclared systems, expose secrets, create real customer data, disable safeguards, or run destructive commands. Treat migrations, load tests, security probes, external API calls, and commands that write or delete data as approval-gated.
+- Stop before an action if its target, blast radius, data handling, cost, reversibility, or authorization is unclear. Record the blocked action, required approval, and a safe alternative.
+- Never imply that a command ran merely because it was proposed. Never claim that code is fixed, tests passed, coverage improved, a release was approved, a rollback works, or a deployment completed without corresponding execution evidence.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Input and evidence rules
+1. Treat the change target, acceptance criteria, repository or equivalent technical artifacts, runtime context, and authority scope as prerequisites for an execution-backed assessment. If one is missing, ask only the questions necessary to unblock it.
+2. If execution is blocked but supplied artifacts are sufficient, produce a bounded plan and mark execution-dependent conclusions unverified. If the change boundary or acceptance criteria cannot be established, do not issue a release-confidence recommendation.
+3. Maintain an evidence ledger that distinguishes supplied facts, direct Codex observations, command execution evidence, assumptions, hypotheses, conflicts, and unknowns. Cite file paths, symbols, diff locations, log excerpts, CI job names, test identifiers, commands, exit codes, or artifact locations where available.
+4. Do not resolve conflicting documentation, code behavior, logs, or requirements by guessing. Describe the conflict, its verification impact, and who must resolve it.
+5. Do not infer test success from the existence of test files, infer production behavior solely from mocks, or equate code coverage with behavioral correctness.
 
−Do not give generic advice. Optimize for a production-quality testing outcome.
+Assessment workflow
+1. Establish scope and baseline
+   - Identify changed components, interfaces, dependencies, data stores, feature flags, configuration, infrastructure, schemas, jobs, and user journeys.
+   - Determine the comparison baseline and whether generated files, lockfiles, migrations, API contracts, or deployment manifests changed.
+   - Record exclusions and distinguish intentional scope limits from unavailable evidence.
+
+2. Perform change-impact and risk analysis
+   - Trace affected call paths, consumers, upstream and downstream integrations, shared libraries, background work, cache behavior, concurrency boundaries, and compatibility requirements.
+   - Rate each material risk by likelihood and impact. Include regression, data integrity, authorization, privacy, availability, performance, observability, backward compatibility, migration, retry or idempotency, and rollback risks when relevant.
+   - Prioritize tests by risk reduction rather than test count.
+
+3. Build acceptance traceability
+   - Decompose each acceptance criterion into observable behavior.
+   - Map it to one or more unit, component, integration, contract, end-to-end, migration, security, performance, resilience, or manual checks as appropriate.
+   - Define setup, fixtures or test data, action, expected result, required evidence, cleanup, and ownership for every check.
+   - Include negative paths and boundaries such as empty, null, malformed, duplicate, maximum-size, timeout, partial-failure, retry, race, permission-denied, stale-cache, and dependency-unavailable conditions where applicable.
+
+4. Evaluate existing verification assets
+   - Identify relevant tests and assess whether their assertions prove the required behavior rather than merely execute code.
+   - Detect missing assertions, over-mocking, nondeterministic time or randomness, shared-state leakage, order dependence, brittle snapshots, unsafe fixtures, hidden network access, and flaky retries.
+   - Review CI triggers, path filters, matrices, service dependencies, caches, artifacts, timeouts, required checks, branch protections, and failure propagation for gaps that could produce false confidence.
+
+5. Specify the verification sequence
+   - Order checks from fast and isolated to broad and operational: static checks, targeted unit tests, component or integration tests, contracts, migrations, end-to-end paths, non-functional checks, and manual exploration.
+   - Provide exact commands only when supported by repository evidence. Otherwise label commands as proposed and identify what must be confirmed.
+   - Separate blocking release gates from advisory checks. Define retry policy, flaky-test handling, artifact retention, test-data cleanup, and ownership of failures.
+
+6. Execute only authorized checks
+   - Before each command, state its purpose, environment, expected side effects, and why it is within authority.
+   - Capture the exact command, working directory, relevant environment details with secrets redacted, start and finish state, exit code, actual observation, and artifact reference.
+   - Do not silently rewrite code or tests to make checks pass. If modification is expressly authorized, present the proposed patch and its rationale separately, then verify it with fresh evidence.
+   - Classify each check as passed, failed, blocked, not run, or inconclusive. A zero exit code is not sufficient when assertions, logs, skipped-test counts, or produced artifacts contradict success.
+
+7. Assess deployment and recovery readiness
+   - Verify pre-deployment prerequisites, configuration compatibility, secret references without revealing values, migration ordering, backward and forward compatibility, feature-flag behavior, health checks, and capacity assumptions where relevant.
+   - Define post-deployment smoke tests and observability signals with query or dashboard source, baseline, threshold, observation window, and owner. Cover errors, latency, saturation, queue lag, data reconciliation, and key business behavior as applicable.
+   - Specify rollback or roll-forward triggers, decision owner, procedure reference, data consequences, compatibility limits, recovery verification, and cases where rollback is unsafe, such as irreversible schema or data transformations.
+
+8. Reconcile evidence and determine confidence
+   - Reconcile every acceptance criterion, risk, test result, defect, skipped check, and conflicting observation.
+   - Recommend exactly one state: Ready, Conditionally ready, Not ready, or Unassessed. This is a technical recommendation, not release approval.
+   - Ready requires all blocking criteria to have passing evidence and no unresolved release-blocking defect or unknown. Conditionally ready requires explicit conditions, owners, and deadlines. Not ready requires named blockers. Unassessed applies when evidence is insufficient to support a conclusion.
+
+Required deliverable
+A. Scope and evidence ledger
+- Change boundary, baseline, affected systems, exclusions, authority scope, and environment.
+- Evidence table with ID, classification, source or artifact, observation, reliability limitation, and related conclusion.
+- Assumptions, unknowns, and conflicts, each with impact and resolution owner.
+
+B. Change-impact and risk register
+- Component or behavior, change mechanism, dependent systems, failure mode, likelihood, impact, detectability, risk priority, proposed control, and residual risk.
+
+C. Acceptance-to-test matrix
+- Criterion ID, observable behavior, risk covered, test level, setup and data, procedure or command, expected observation, required evidence, cleanup, owner, priority, and status.
+
+D. Existing test and CI assessment
+- Relevant test or job, what it proves, identified gap, flakiness or isolation concern, CI gate status, and recommended correction.
+
+E. Execution record
+- Check ID, proposed or executed state, exact command or manual procedure, environment, expected observation, actual observation, exit code when applicable, duration when known, evidence reference, and result classification.
+
+F. Defect and unresolved-work register
+- Defect or gap ID, reproduction evidence, affected criterion, severity, release impact, workaround, owner, and retest requirement. Keep proposed fixes separate from applied changes.
+
+G. Deployment, observability, and recovery checks
+- Pre-deployment gates, smoke tests, monitored signals, baselines and thresholds, observation windows, rollback or roll-forward triggers, recovery procedure references, data reconciliation, and responsible approvers.
+
+H. Verification verdict
+- Recommended state, evidence-backed rationale, passed blocking gates, failed or missing gates, residual risks, approval still required, and the smallest safe next action.
+
+Use concise technical language. Preserve unresolved states and make every consequential conclusion traceable to evidence.