A launch decision should be based on known coverage and known risk — not only on whether the main screen looks complete. Use this checklist to validate critical journeys, permissions, integrations, environments, and recovery before release.
A launch decision should be based on known coverage and known risk — not only on whether the main screen looks complete. Use this checklist to validate critical journeys, permissions, integrations, environments, and recovery before release, so the launch decision is a deliberate one rather than a hopeful one.
Before testing begins, confirm exactly what is being released, who owns the decision to ship, and which browsers, devices, and environments are actually supported. Testing without a clear scope tends to drift toward whatever is easiest to check, rather than what actually carries risk.
Identify the small number of journeys the product cannot fail at — account creation, checkout, core workflow completion — and test each one end to end, including realistic variations, rather than only the ideal path. A journey that works in isolation can still fail once real data and real timing are involved.
Confirm that each user role sees only what it should, that permission boundaries hold under direct URL access and not only through the interface, and that account states like suspended or expired behave correctly. Permission errors are disproportionately damaging because they expose data rather than simply breaking a feature.
Every form needs both valid and invalid input tested, along with the notifications and feedback a user receives at each step. A form that silently fails, or that gives no indication that a submission succeeded, creates support burden even when the underlying logic is technically correct.
Anything the release depends on that Punctipes or the team does not fully control — payment providers, external APIs, a CMS, or other third-party services — needs explicit validation of both success and failure behavior, since these dependencies are where release-day surprises most often originate.
New work can affect existing functionality in ways that are not obvious from the change itself. Regression testing should cover the areas directly touched by the release plus the business-critical journeys that would be most damaging to break, even if they were not part of the intended scope.
Confirm the release actually works across the browsers and screen sizes defined as supported — not just the one used during development. Layout and interaction problems that only appear on specific devices are a common source of post-launch issues that a broader testing pass would catch.
Confirm production configuration matches what was tested, monitoring and logging are active and actually useful for diagnosing a problem, and a rollback path exists and has been considered in advance. Discovering that rollback is not actually possible during an incident is a preventable failure.
Confirm with the appropriate specialists that privacy notices, consent mechanisms, and accessibility requirements relevant to the product and its markets are addressed before launch, rather than treated as a follow-up task after release.
No release is entirely free of known issues. What matters is that they are documented, explicitly prioritized, and reviewed by the person responsible for the go/no-go decision — so launching with a known limitation is a deliberate choice, not an oversight discovered afterward.
Tell us what is changing and which user journeys cannot fail. We will help define practical test coverage for the release.