Write the expected result before trying the form. Record the starting state, exact input, action and evidence needed to decide whether it worked. Use invented details so the plan can be shared without copying customer records.
A normal request is only one case. Include a valid unknown answer, invalid input, missing required information and repeated actions. Also check that a later, different request from the same person can follow the rule you chose.
The furniture-repair example below is fictional. Its saved records, messages and duplicate rules are proposed requirements. No cases have been run, and no ClickFunnels AI behavior is established by this guide.
Define where a future check may run
Name the exact page version, permitted environment and destination to inspect. Record whether submitting could send an email, notify a team, start another workflow or create a billable action. Before running a case, confirm the environment and its outbound behavior with the person responsible for it.
Use reserved example addresses in the written plan, such as [email protected]. RFC 6761 reserves .example and its descendants for documentation. It also specifies ordinary application handling of example names. An example address does not switch off notifications or other effects.
These fixtures do not provide an inbox for delivery testing. If the actual form checks deliverability, arrange an appropriate controlled test address and record that substitution. Keep production validation intact. Use an inbox you control for a separately authorized delivery check.
Set the fictional request rules
Imagine a furniture-repair business collecting enquiries for later review. The proposed form has four fields:
| Field | Fictional rule |
|---|---|
| Reply email | Required; a correctly formed email address is needed for this example |
| Service | Required choice: Chair repair, Table repair, or Not sure |
| Description | Required short explanation of the item and problem |
| Timing | Optional choice: This month, Next month, or Not sure |
For this example, a saved enquiry produces “Enquiry saved for review.” It does not book a repair, produce a quote or prove an email arrived. A rejected input produces an explanation without claiming the enquiry was saved.
The chosen repeat rule is one enquiry for repeated activation of the same submission attempt. A later enquiry about a different item remains a separate request, even with the same email. This is a planning decision to implement and verify, not a built-in product capability or a rule every business must use.
Prepare six complete cases
Each case below has its own starting state. Counts refer only to that case's controlled test records, not all records in a real account. Use the case ID in your test notes; it is not an assumed form field.
F01 — A normal enquiry
Input: [email protected]; service Chair repair; description Loose front leg on wooden chair.; timing This month.
Start with no records for this case. Activate the submission once. The expected result is one saved enquiry containing those exact values, followed by the saved-for-review message. Inspect both the visitor result and the intended record destination. A message on the page alone cannot establish the stored values.
Expected case count: 0 → 1. Observed result: not run.
F02 — The visitor does not know the service or timing
Input: [email protected]; service Not sure; description Need help deciding whether a stool can be repaired.; timing Not sure.
Start with no records. The expected result is one enquiry retaining both unknown choices. The example permits these answers, so the visitor should not have to invent a service or date to proceed. Check that the saved record does not silently replace either answer with the first option in a list. The owner still needs to review the request.
Expected case count: 0 → 1. Observed result: not run.
F03 — The email is missing its @ sign
Input: case.invalid.funnel.example; service Chair repair; description Loose front leg on wooden chair.; timing This month.
Start with no records. The expected result is a clear email correction message, no saved-for-review message and no new enquiry. Keep the other entered information available while the visitor corrects the field. The deliberately malformed value tests the proposed format rule; it is not a mailbox or a test of email delivery.
Expected case count: 0 → 0. Observed result: not run.
F04 — A required description is empty
Input: [email protected]; service Chair repair; description empty; timing This month.
Leave the description field empty; do not enter the word “empty.” The expected result is a message identifying the missing description and how to correct it. The other values should remain available. No enquiry should be saved under this example's rules, and the page should not claim receipt.
Expected case count: 0 → 0. Observed result: not run.
F05 — The same submission is activated twice
Input: [email protected]; service Chair repair; description Loose front leg on wooden chair.; timing This month.
Start with no records. In a permitted check, activate the same submission twice in quick succession. The proposed result is one enquiry with the entered values. Record what the interface shows and inspect the case's destination records after the attempt settles. A disabled button is useful interface evidence, but does not establish the final record count.
Expected case count: 0 → 1. Observed result: not run.
F06 — A later, different enquiry uses the same email
Prepare this case independently with one earlier fictional enquiry: [email protected], Chair repair, Loose front leg on wooden chair., This month. Confirm that controlled starting record before checking the new request.
New input: [email protected]; service Table repair; description Wobbly table base.; timing Next month.
Start a new submission attempt. Under the chosen rule, the expected result is a second enquiry. The earlier chair enquiry should remain unchanged. This catches an overly broad rule that treats the email address alone as proof that every later request is an accidental repeat.
Expected case count: 1 → 2. Observed result: not run.
Make failures understandable
For F03 and F04, specify more than “shows an error.” Identify the affected field, the correction the visitor needs to make and the information that should remain available. W3C's form notification guidance explains the importance of clear messages that identify the relevant control and help users correct mistakes.
Include a check that the affected field and submit control remain reachable with the keyboard and that focus can be seen. W3C’s Easy Checks covers these initial observations. Inspect the rendered behavior in the actual supported browsers and assistive setup you are evaluating. These focused checks do not constitute a complete accessibility evaluation.
Keep browser behavior separate from destination validation. W3C's validation guidance explains why client-side validation alone is insufficient. A browser rejecting F03 does not prove how the receiving system handles invalid data. Record that second question for the person authorized to inspect the implementation or its tests; do not infer an unseen result.
Keep the starting state and observations separate
Playwright's testing guidance recommends tests that run independently with their own state. Apply that principle to this plan: give each case its stated baseline. F06 deliberately includes an earlier record within its own setup; it should not depend on F01 having run.
For each permitted run, record the page version, environment, date, actual inputs and observed result. Attach the evidence for the claim being checked. Use not run, blocked, pass or fail, with a reason. Missing access to the destination leaves the saved-record check blocked even if the page message looks correct.
Identify any test records to remove through the agreed cleanup process. Do not use a general delete action or alter customer records to reset a case.
Use the test-plan worksheet
The plain-text test plan contains the environment record, all six complete cases, blank observation fields and a reusable case template. Adapt its rules to your actual enquiry process before running anything. Add further cases where your project has different conditions, such as a failed save or a retry after an interrupted response.
For a ClickFunnels AI project, keep the plan with your instructions and consult the agent guide for access and workflow requirements. This worksheet supplies expected checks; it does not grant access, create a test environment or establish that a generated funnel works.
Common questions
Can an invented address prove that an email was delivered?
No. A written fixture supports the case plan. Delivery needs a permitted check through the actual process to an inbox you control.
Should a repeated email always be rejected?
Decide what counts as a repeat in your workflow. F05 repeats an attempt; F06 starts a different enquiry. An email address alone does not describe the visitor's intent.
Can a case pass when only the visible message was checked?
Only that visible-message check has evidence. Keep saving, stored values and any later delivery separate, with their own observations.