Q12 of 22 · Scenarios

How would you test a comment / review submission feature?

ScenariosMidscenariocommentsreviewssecurityxssidor

Short answer

Short answer: Clarify authentication requirements, moderation flow, and length limits. Then cover submission correctness, XSS/injection in content, IDOR for edit/delete, and duplicate submission prevention.

Detail

Clarify first

  • Must the user be authenticated to submit a comment?
  • Is content published immediately or held for moderation?
  • What is the character limit, and is rich text (HTML/Markdown) or plain text only?
  • Can users edit or delete their own comments?

Functional

  • Valid comment appears under the correct item after submission; author name and timestamp accurate
  • Edit updates the content; an "edited" indicator appears if required by design
  • Delete removes the comment from the view (soft delete or hard delete?)
  • Comment is associated with the correct entity (product, post, article ID)
  • Pagination of comments works correctly when there are many comments on an item

Negative / error handling

  • Empty comment → not submitted; validation error shown
  • Comment exceeding the maximum length → rejected with a clear message showing the limit
  • XSS in content (<script>alert(1)</script>) → stored and rendered as plain text; no script execution
  • HTML injection (<img src=x onerror=alert(1)>) → sanitised before rendering
  • Double-click or network retry → duplicate submission prevented (idempotency key or debounce)

Edge & boundary

  • Very long single word with no whitespace → renders without breaking the layout
  • Unicode and emoji in the content → stored and displayed correctly
  • Comment submitted on an item that is deleted concurrently → handled gracefully
  • Comment on page 100 of a paginated comment thread → still loads correctly

Security

  • XSS: rendered comment must not execute injected scripts — test both stored and reflected vectors
  • CSRF: comment submission form has a CSRF token that is validated server-side
  • IDOR: user A cannot edit or delete user B's comment by changing the comment ID in the request
  • Rate limiting: rapid successive submissions from the same user are throttled

Moderation

  • If applicable: comment in "pending" state is visible to the author but hidden from other users; moderator can approve or reject

Close: automate XSS payload submission and assertion that output is escaped, IDOR check via API, duplicate submission prevention, and length validation. Keep manual for moderation queue behavior and rich-text rendering edge cases across browsers.

// WHAT INTERVIEWERS LOOK FOR

XSS sanitisation (stored and rendered, not just rejected), IDOR on edit/delete, and CSRF protection. These are the security concerns that separate a thorough answer from a functional-only one.

// COMMON PITFALL

Testing only the happy path and character limit. XSS in user-generated content and IDOR on edit/delete are common vulnerabilities that basic UI testing won't catch.