Review a form from the first promise to the final result

Review a journey, not an empty screenshot

Begin where the reader encounters the invitation. Record the promise, the identity of the publication and the action being offered. Then follow the route through the form, its response and any email or resource. A form can look finished while one of those later steps remains unavailable.

Use a short result record with the case tested, the expected outcome, the observed outcome and what still needs attention. This makes a review useful to the person fixing the system and avoids presenting a prepared form as an operational service.

Inspect the invitation and controls

Check that labels remain available while typing and that optional fields are identified. Read the button as part of the surrounding promise. Make sure the form distinguishes a contact enquiry from a newsletter signup or a request for a file.

Try the journey at a narrow viewport, with keyboard navigation and with longer input and feedback. The accessibility guide explains what to inspect in labels and notifications, while email validation describes the difference between a format check and evidence of address control.

Exercise failure states deliberately

Test an omitted required value, an unsupported value, a repeated submission and an unavailable downstream service. Check that the person is told what can be corrected and that safe input is preserved. A generic success message should not appear merely because a request was started.

Treat an uncertain result differently from a known validation error. A failure before processing can be explained as an unaccepted request; a connection lost after processing may require checking status before trying again. Keep the same distinction in any internal report.

Worked example: a resource signup

Imagine a publication offering a worksheet. The review starts at the article’s resource invitation, moves to the form and then checks the stated next step. The tester follows any confirmation process, obtains the worksheet, opens it on a phone and checks the contact route shown beside it.

A second controlled request checks the duplicate behaviour. Another test uses an unavailable resource destination so the team can see whether the error is understandable. The result record identifies which checks used a test environment and which, if authorised, exercised the real service; it never describes a dry run as a delivered email.

Three labels for what a result means

Record the environment and outcome separately. The following labels distinguish known no-transport dry runs, authorised real-service tests and unresolved outcomes.

A success-style message in a dry run demonstrates displayed wording, not delivery. Keep separate records when the same case is exercised in two environments.

• Dry run: the environment is known to have no mail transport and no real audience. When that is known, the record may say that no message was sent. It exercises validation, wording and routing only and must never be reported as a delivered email.
• Authorised real-service test: exercise the live service with a controlled account and synthetic content, recording authorisation beforehand. The observations support claims only about the route and conditions tested; the label itself is not evidence.
• Uncertain result: the tester cannot tell from the evidence whether the request was processed, for example because the connection dropped after the button was pressed. The record says so and does not become ‘sent’ or ‘not sent’ until a status check supplies evidence.

A compact end-to-end test matrix

Choose controlled accounts and synthetic content, and record the environment for each case. A private dry run should exercise its intended boundaries without sending to a real audience.

• Valid request: the result describes the exact state the application established.
• Required value missing: the relevant error is understandable and safe input remains available.
• Malformed or unsupported value: the request is rejected without invoking the downstream operation.
• Repeated request: the system follows the stated duplicate rule.
• Service unavailable or ambiguous response: the interface avoids claiming completion and provides an appropriate next step.
• Resource destination missing: the journey explains the problem instead of claiming a usable download.
• Stop or preference change: the recorded result is reflected in the relevant sending eligibility.

Record 1 (dry run): a valid request

The following records describe a fictional worksheet signup for Harbour Notes; none reports a real test.

• Case: a valid request for the worksheet, using a synthetic address.
• Expected: the page states the exact state the application established and says plainly that nothing was sent because this is a dry run.
• Observed (hypothetical): “Dry run complete. The request passed validation. No message was sent because this environment has no mail transport.”
• Evidence: a screenshot of the page text, and an environment note written before the run stating that no transport was connected.
• Environment: private dry run, no real audience, synthetic address.
• Reading: the screenshot supports the displayed wording and reported validation state, not an independent finding that all validation worked. It establishes nothing about delivery, confirmation links or the download.

Record 2 (authorised real-service test): the same request, end to end

Same invented signup, now exercising the live service.

• Case: the same request using a controlled mailbox belonging to the team.
• Expected: the page says the request is pending confirmation; a confirmation message reaches the controlled mailbox; after confirmation the worksheet link works and opens on a phone.
• Observed (hypothetical): “Request received. Check your inbox for a message asking you to confirm. Your subscription is not active until you confirm.” A message arrived; its link led to an active-state page; the worksheet opened on a phone.
• Evidence: screenshots of each page, the saved message, and a written authorisation note dated before the test.
• Environment: live service, authorised, controlled account, synthetic content, one mailbox, one phone.
• Reading: pass for this route with one mailbox and one phone. No claim is made about other mailboxes, other devices or future submissions.

Record 3 (dry run with a recording stand-in): a malformed address

Same invented signup, now testing a rejected value.

• Case: an address typed without a domain, “reader@”.
• Expected: the request is rejected before the downstream operation; the error names the field and the correction; the typed value is preserved.
• Observed (hypothetical): “Email address: this address is missing a domain, for example name@example.org. Please check it and try again.” The field still held “reader@”.
• Evidence: a screenshot, plus the test setup’s own record that the stand-in for the downstream service received no call.
• Environment: test environment in which the downstream service is replaced by a recording stand-in; no real audience.
• Reading: pass. The stand-in’s empty call record supports ‘rejected without invoking the downstream operation’; a screenshot of the message alone would not. The real service’s handling of this value is not shown.

Record 4 (uncertain result): the connection drops

Same invented signup, now an ambiguous response.

• Case: a valid request submitted from a phone whose connection dropped just after the button was pressed.
• Expected: the interface avoids claiming completion, keeps the entered values and gives a next step.
• Observed (hypothetical): “We could not confirm that your request was received. Please check your inbox for a confirmation message before trying again.” The values were still in the form. Later the controlled mailbox showed no message, and the tester had no access to the service’s own record.
• Evidence: a screenshot, the time of the mailbox check, and a note that no server-side record was available.
• Environment: live service, authorised under the same note as Record 2, controlled account, mobile connection interrupted by the tester.
• Reading: interface behaviour passes; the outcome of the request is UNCERTAIN. An empty mailbox does not show that nothing was processed. Next step: ask the service owner for the status record before retrying the same address, and keep this record open.

Cases the four records leave open

These records leave duplicate handling, a missing resource and stop or preference changes untested. Mark each ‘not run’; keep Records 1 and 3 limited to their test environments.

Check operation and ownership

Confirm that the configured sender, recipient and publication identity are trusted values. Inspect rate controls at the application and proxy boundary, and check which logs or providers retain data. Use synthetic examples rather than real subscriber lists in ordinary development work.

Finally, name the maintainer of the public URL, the resource and the follow-up message. Keep an inventory of those links so a change of platform does not strand them. The retired-link guide is useful when a route has reached the end of its life.

Make a release decision from the evidence

Separate cosmetic issues from failures that prevent a promised operation or misstate its outcome. A test can demonstrate a specific route under specific conditions; it does not certify every future submission. Write down the remaining limitation instead of hiding it behind a large test count.

A practical release record ends with what is ready, what is deliberately disabled and what evidence would permit the next step. Connect that record to the subscriber lifecycle so the form, email system and editorial team describe the same operation.

A release note drawn from the four records

Use these results to write a release note. The e-book delivery guide covers the next stage.

• Ready: displayed feedback for a valid request (Record 1); rejection before the recording stand-in for the malformed case (Record 3); confirmation and worksheet access for one mailbox and phone (Record 2).
• Deliberately disabled: the form stays unlinked from the worksheet article.
• Open: the outcome of the interrupted request (Record 4), the repeated request, the missing resource destination, and stop or preference change.
• Evidence that would permit the next step: the service owner’s status record for Record 4, passing authorised records for the three unrun cases, and a named maintainer for the public URL and the worksheet.