What tests should be performed after the application goes live?

What tests should be performed after the application goes live?

After an application goes live, perform controlled smoke tests against the actual production URL. These tests confirm that the deployed code and production configuration work together. They complement the broader testing completed before release.

For a wedding application, use designated test accounts and records so verification does not change real plans, contact real guests unexpectedly, or remove user content.

Walk through the released journeys

Test the homepage, signup or login, onboarding, and dashboard according to the release scope. Verify that wedding information remains after refresh and a new session.

If editing is included, change a test venue and confirm persistence. If invitations are included, send to an approved test recipient and follow the link through acceptance. Exercise uploads only when that feature is part of the release.

Check important navigation and forms on a narrow mobile viewport, including keyboard access and readable validation feedback.

Confirm access boundaries and failure handling

Use separate accounts to verify that one wedding cannot access another's private information. Check signed-out access to protected pages and endpoints. If roles exist, test the capabilities relevant to organizers, collaborators, and guests.

Keep destructive testing and deliberate service failures in staging unless there is an explicitly controlled production procedure. In production, verify safe error handling through bounded cases such as invalid form input or an expired test invitation.

Inspect the deployment itself

Confirm the expected commit and environment are live. Review application errors, failed requests, database connectivity, and available service health signals. A page loading successfully does not prove that background integrations are healthy.

Record test results, remaining gaps, and any follow-up owner. If a core journey is broken, use the release recovery process rather than continuing to promote the application.

Repeat only the relevant checks after a fix, while watching for related regressions. This turns the launch into an observed result instead of relying solely on a successful build indicator.