Playwright Form Fuzzing

Tests forms the way real, messy human input actually happens — empty submissions, names with apostrophes, absurdly long strings, unicode, malformed dates — and checks whether the app handles each one with a clear message or falls over.

Scope boundary — read this first

This is robustness and UX testing, not security testing. The goal is confirming graceful degradation, not finding exploitable vulnerabilities. Concretely:

• Never use SQL syntax, script/injection payloads, or anything crafted to execute code or manipulate a query.
• Never attempt to bypass authentication, access another user's data, or escalate privileges.
• Never attempt to confirm, reproduce, or exploit something that looks like a security vulnerability once observed — flag it and stop.
• If a finding looks security-relevant (unescaped output, a leaked stack trace or internal error message, anything suggesting the app isn't sanitizing input the way it should), the record should say "possible security-relevant issue — recommend proper security review" and go no further. That's a different discipline with different tooling and different people who should own it; this skill's job ends at noticing something worth their attention, not investigating it.

Core principles (and why)

A good validation failure is specific and actionable — not just "the app didn't crash." "Please enter a valid email address" is a pass. A raw stack trace, a blank page, or a generic "something went wrong" for a simple format mistake is a fail, even though the server technically stayed up. Judge the quality of the failure mode, not just survival.

Real-but-unusual input matters more than purely synthetic edge cases. A name field that rejects "O'Brien" or "Müller" is a real bug affecting real people, arguably more worth catching than an extreme boundary case almost nobody will ever hit. Weight the input set toward what's actually likely to occur, not toward maximum weirdness for its own sake.