A screenshot shows what a form looks like, but it does not let anyone check how it behaves. For reviewing changes, it is better to prepare a working version. The client opens it in a browser and goes through the scenario the job was about.
Decide what is ready for review
Before you send the address, check the changed features. Choose a specific version and write down the scope of the review. If you are developing further elements at the same time, keep them in a separate environment, so that the preview does not change while the client is testing.
Prepare test data and any account needed in the application. If you are using a copy of production, check the database, email and integrations. A form test should not send a message to a real store customer.
Check access from the client’s point of view
Start the project from Contextadmin and configure public access. Set up HTTPS and a password if the preview is meant to be private. Open the link in a window with no saved session and check that the password really is required.
To review the application, its address is enough. An account in the development panel is needed only when you give the client access to a broader working environment.
Add a short task to the link
Write what has changed and how to check it. For example: “We added a choice of pickup point. Go through the cart on a computer and on a phone. These are test orders, and no payment is taken.” Use a message like this only if it matches the actual configuration of the preview.
Ask for a description of the steps that lead to the problem instead of just “it doesn’t work”. The address of the view, the type of device and the expected result make the error much easier to reproduce.
Collect feedback with the right task
Move the comments to the context for this change. Mark which are fixes and which extend the scope. Once the fixes are in, send the same scenario for another check.
Record the approval together with the project version. It will be your reference point when preparing the production release.