QA Exercise 11

1. Basic submit: Fill in all fields with valid data and submit once. Notice the status message.
2. Invalid email: Change the email to an invalid format (e.g., alex@, alex@@test) and submit again.
3. Short message / bad rating: Enter a very short message (e.g., 5–10 characters) and rating values such as 0, 6, or 3.5, then submit.
4. Anti-spam check: Try different answers for the spam question, including correct and incorrect ones.
5. Duplicates: Send the same name with a different email, and then same name & same email multiple times. Watch the submissions counter and status.
6. Spoken report: Present your bug report orally, covering:
   • Title
   • Steps to Reproduce
   • Expected vs Actual result
   • Severity / Priority
   • Recommendation for the dev team

• form validation — checks that user input meets specific rules before submission.
• client-side validation — validation that runs in the browser (e.g., JavaScript, HTML5).
• server-side validation — validation that runs on the backend to enforce rules securely.
• required field — a field that must be filled in, otherwise the form should fail.
• error message — text that explains what went wrong and how to fix it.
• confirmation message — text shown when the action completes successfully.
• duplicate submission — sending the same feedback more than once, often by accident.
• spam protection — measures to prevent automated or irrelevant submissions.
• data quality — how accurate, complete, and reliable the collected data is.
• edge case — a rare or extreme input that can reveal hidden bugs.

• enforce required fields / enforce minimum length
• validate email format / reject invalid addresses
• display a clear error message / provide feedback to the user
• prevent duplicate submissions / throttle rapid requests
• capture high-quality feedback / filter out spam
• log submissions on the server / audit feedback data

• slip through the cracks — get missed by validation: “Short messages slip through the cracks.”
• flag up — mark as a problem: “The form doesn’t flag up invalid emails.”
• bounce back — be rejected and returned: “Invalid input should bounce back to the user.”
• lock down — secure or tighten rules: “We need to lock down spam protection.”
• iron out — fix and smooth: “We still need to iron out these validation bugs.”

Bug title: Feedback form accepts invalid data and shows success for submissions that should fail.

Steps to reproduce: First, enter a valid name but use an invalid email like alex@, a rating of 0, and a very short message like “ok”. Set the spam answer to 5 and submit. Then, submit the same name and email multiple times in a row.

Expected result: The form should block invalid emails, enforce a rating between 1 and 5, require a longer message, and prevent duplicate submissions. It should display clear error messages and only show a success message when validation passes.

Actual result: The form often accepts invalid emails, allows out-of-range and decimal ratings, and lets very short messages slip through. It shows a success message even when fields are clearly wrong, and duplicate submissions with the same data are not blocked or flagged.

Severity / Priority: Medium to high severity, P1 priority — data quality is poor and spam/invalid feedback can easily slip through, which affects analysis and user trust.

Spoken summary:
“In this feedback form I ran into several validation issues. Invalid emails, out-of-range ratings, and very short messages all slip through the cracks, and the system still shows a success message instead of bouncing the input back to the user. It also doesn’t prevent duplicate submissions. I’d flag this as a P1 issue and recommend locking down server-side validation, tightening the email/rating/message rules, and showing specific error messages so users know exactly what to fix before the feedback is accepted.”