Follow the record, not just the button
A successful animation after pressing Save can conceal an unsaved request. Test a representative action, reload the page and inspect the persisted result through an authorized view. Confirm that the record belongs to the right organization and user. Repeat with incomplete data. The interface, backend validation and stored state should tell one consistent story rather than three competing versions of success.
Test the person who must be refused
For a customer portal, sign in as a second customer and attempt to reach the first customer’s record. Do not rely on a hidden navigation link as access control. The server should refuse the operation. In a shared workspace, also test an ordinary contributor against owner-only actions. Write these forbidden paths into acceptance criteria before implementation so they cannot be removed merely to obtain a green result.
Design for interruption
Close a tab during a long operation, reopen it and confirm that the state is understandable. Simulate an integration timeout in a permitted test environment. A retry must not create a second order or send the same message twice. Distinguish the request being received, the work finishing and the result being delivered. Each transition needs an explicit state rather than an endless spinner.
Accept the deployment environment separately
The same code can behave differently when runtime versions, storage permissions or background workers differ. Record the release being tested and the target configuration. Preview acceptance confirms that particular test result, not every future destination. Forge connects the release, evidence and deployment decision so a customer can ask what was actually checked before a production change.
Trace a real record through the system
A polished home page can conceal a failed save, a missing background worker or a public attachment URL. Choose a complete customer job and follow it from the initial input to the stored result. Reload the record, change sessions and inspect the relevant permission boundary. This tests whether the application works beyond the first successful screenshot.
For a service request, verify creation, validation, assignment, status history and notification intent. The notification can be captured in a test outbox rather than sent to a real customer. Record the exact build and configuration used so that evidence is not accidentally carried over to a different release.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Data | The saved result survives reload. | Read the persisted record. |
| Permissions | A second customer cannot access it. | Negative tests in a second session. |
| Operations | Required workers and jobs are configured. | An observed bounded job and recovery test. |
Where this goes wrong
Do not infer delivery from an enqueued email, successful payment from a test request, or backup safety from a copied database. Every claim needs the corresponding evidence. External services may be mocked for isolated tests, but those results must remain distinct from verified live integration behavior.
A convincing demo starts a review; it does not replace acceptance.
Turn it into a working checklist
- Reload after saving.
- Test cross-customer access.
- Exercise retries without duplicate actions.
- Bind evidence to the exact release.
A concrete next step
Prepare a release checklist with owners for application checks, data migration, runtime services and recovery. A release is accepted only for the checked scope; untested paths should be recorded as open work rather than hidden in a general green status.
Watch a related case
The video could not be loaded. Try again later.