Test cases for a contact form
Updated 2026-11-13 · 6 min read
These 30 cases use explicit test fixtures and checkable outcomes. Cover normal behavior, boundaries, recovery, security and usability, then adapt the requirements to your product.
How to answer in an interview
Ask which fields are mandatory, where submissions go, whether attachments exist, and what the success message promises. Cover validation and the handoff to the support queue separately. A green toast does not prove that a support request was stored.
Scope and test data
These 30 cases assume name, email, topic and message fields, with an optional phone number and no attachments. Use Asha Test, [email protected] and 9000000001 only as synthetic fixtures. Route every notification to a local mail sink; do not send real email.
For this example, trimmed names allow 1–80 characters and trimmed messages 1–2,000 characters, counted by the application's documented character rule. Topics are Sales and Support. One submission creates one queue record and a reference ID; success means accepted into that queue, not read by a person. Define the throttle threshold and latency target in the test plan before executing the relevant rows.
These are proposed manual test cases, not an execution report. Run security and load checks only in an authorised isolated environment. Record agreed limits before execution; a case without its required limit is not ready to pass or fail.
Validation and useful input
| ID | Category | Test case | Expected result |
|---|---|---|---|
| C01 | Functional | Submit valid required fields with phone left empty | One queue record contains the entered values and a reference ID is displayed |
| C02 | Negative | Submit all fields empty | Each required field is identified; no queue record is created |
| C03 | Negative | Omit each required field separately | Only the missing field is reported; other entered values remain |
| C04 | Negative | Enter only spaces for name or message | Required-field error appears after trimming |
| C05 | Functional | Use a name containing an apostrophe, hyphen or Hindi characters | The name is stored and displayed without corruption |
| C06 | Negative | Enter asha@ as the email | An email-format error blocks submission |
| C07 | Functional | Use [email protected] in the isolated mail sink | Valid address is preserved; submission is accepted |
| C08 | Functional | Paste a multiline message with punctuation and Hindi text | Line breaks and text survive in the support record |
| C09 | Boundary | Use trimmed names of 1, 80 and 81 characters | First two pass; 81 is rejected with the name limit |
| C10 | Boundary | Use trimmed messages of 1, 2000 and 2001 characters | First two pass; 2001 is rejected without silent truncation |
Submission and recovery
| ID | Category | Test case | Expected result |
|---|---|---|---|
| C11 | Functional | Choose each supported topic | Stored topic matches selection and routes to its configured test queue |
| C12 | Negative | Change the topic to an unknown value in the request | Server rejects it; no arbitrary queue is selected |
| C13 | Functional | Double-click Submit during a slow response | One accepted submission and one reference ID result |
| C14 | Negative | Disconnect before submission reaches the server | No success is shown; entered fields remain available for retry |
| C15 | Negative | Lose the response after the server accepts the request, then retry | Retry resolves to the same logical submission without a duplicate queue entry |
| C16 | Negative | Simulate queue persistence failure | Failure is shown; the form does not claim successful acceptance |
| C17 | Functional | Refresh after successful submission | No automatic resubmission or second support record occurs |
| C18 | Functional | Inspect the sink notification after acceptance | Reference, topic and message match the queue record; recipient is the configured test sink |
| C19 | Functional | Fail notification delivery after queue acceptance | Accepted record remains available; notification failure is observable for retry |
| C20 | Negative | Expire an authenticated session before submit, if login is required | Reauthentication is requested without accepting the request under another identity |
Abuse, usability and operational checks
| ID | Category | Test case | Expected result |
|---|---|---|---|
| C21 | Security | Bypass browser validation and submit an overlength message | Server enforces the same limit; no oversized record is stored |
| C22 | Security | Submit markup-like text and inspect the support viewer | Text cannot execute scripts in the form, confirmation or support interface |
| C23 | Security | Put newline characters in a field used to construct mail headers | Input cannot add recipients or extra headers to the sink message |
| C24 | Security | Exceed the configured submission throttle in an authorised test | Further submissions are limited with a retry explanation; accepted count matches policy |
| C25 | Security | If cookie-authenticated, submit from an untrusted origin | Request is rejected by the application's cross-site request protection |
| C26 | UI | Submit errors using keyboard and screen reader | Fields have labels; errors are associated with fields and focus reaches a useful correction point |
| C27 | UI | Submit successfully with a screen reader active | Acceptance status and reference are announced without requiring visual inspection |
| C28 | Compatibility | Complete the form on supported mobile and desktop browsers | All required values and the reference survive each submission path |
| C29 | Performance | Submit the agreed peak workload to the test queue | Acceptance latency meets the recorded budget; accepted requests are neither lost nor duplicated |
| C30 | Security | Inspect URLs and routine analytics after submission | Message, email and phone do not appear in URLs or analytics events |
Prioritise the queue boundary
Start with valid submission, missing fields, server-side validation and retry after an ambiguous timeout. Capture the reference ID and inspect the test queue through authorised tooling. A request that was accepted but whose notification failed is a different defect from a request never stored.
The common interview mistake is promising that an email “must arrive immediately.” Ask what acceptance and delivery mean, who owns retries, and which service-level target applies. Browser validation improves feedback but does not replace server validation.
Downloads
Quick answers
Does successful submission prove email delivery?
No. Check queue acceptance and sink delivery separately. The confirmation should describe only the stage that has completed.
Should a contact form require a phone number?
Only if the product needs one. Test the documented optional or required rule without assuming every contact must use an Indian mobile number.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.