🏭 Edge Case Factory

Edge Case Factory: Using Claude as an edge-case factory is a materials-testing lab that never just checks whether a bridge holds normal traffic — it deliberately tests the load l

Using Claude as an edge-case factory is a materials-testing lab that never just checks whether a bridge holds normal traffic — it deliberately tests the load limit, freezing cold, a slightly overweight truck, and someone actively trying to break it — and the mechanism matches one-to-one, not loosely: equivalence-class partitioning already taught you to group possible inputs into a handful of representative classes (valid, invalid, boundary...); asking Claude to GENERATE concrete values for each class turns a manual, error-prone brainstorming step into a fast, systematic one. Here is the question worth sitting on: you already know equivalence-class partitioning as a technique — why do you need Claude for this at all, isn't listing "boundary, empty, special character" just something a QA engineer already does from memory? Because knowing the CATEGORIES is not the same skill as producing realistic, varied VALUES inside each one under time pressure — most testers, typing from memory, reach for the same three familiar special characters and never think to try an actual right-to-left script, an actual combining-character Unicode edge case, or an actual XSS payload shape a real attacker would use. Java comparison: this is the difference between hand-writing every @ParameterizedTest case for a validator and using a property-based testing library (in the JVM world, jqwik or QuickCheck-style generators) that produces the input space for you — you still design the CATEGORIES, that remains the QA judgment call, but the generator (here, Claude) fills each one with realistic representative values faster and with more genuine variety than typing from memory ever would. The QA stake: a form validator tested only with English names that silently mangles a real Turkish customer's name (the dotted-capital-I / dotless-lowercase-i letters are a classic trigger), or a field that happily accepts 5,000 characters and crashes a downstream database column, are real production incidents — the 8-category factory below exists specifically to turn "did we even try a Unicode name?" into a checkbox, not a forgotten afterthought.

The Logic of the 8 Categories

Each category targets a distinct, real failure mode, not an arbitrary checklist item. Valid is the happy-path baseline everything else is compared against. Invalid is classic negative testing. Boundary catches off-by-one and min/max errors. Empty triggers null-object and required-field logic. Special characters expose parsing and injection assumptions. Unicode catches internationalization bugs — the Turkish dotted-capital-I / dotless-lowercase-i case-folding bug below is a real, recurring example, not a hypothetical. XSS is a security check specifically for anywhere user input is later rendered as HTML. Too long targets buffer limits and database column overflows. Missing any one of these leaves a specific, nameable class of production bug untested — not a vague "more testing is better" gap.

Pick a field type below and browse all 8 categories — each one is copyable, and the full set downloads as JSON for a real test suite. The two prompt templates underneath are meant to be reused: swap in your own field name and format description to have Claude generate the same 8-category breakdown for a field this factory doesn't already cover.

🎬 From Happy Path to an Edge-Case Factory

"We tested the payment flow" is said — but was it tested ONLY when card details are entered correctly?

The happy-path flow is given to Claude: "list ALL the ways this can break" is requested.

Dozens of edge cases pour out: network drop mid-payment, double-click, expired card, negative amount, two concurrent payments...

The raw list is TOO broad — testing everything is impossible. Claude is asked to PRIORITIZE by business impact.

Principle: generating edge cases is the easy part — the real QA skill is deciding which 5 are actually WORTH testing.

Step by Step: From Raw List to Prioritized List

Raw list: 40+ edge cases

Claude generates dozens of possible breakage paths for the payment flow — all THEORETICALLY possible.

Each is scored by business impact