UI test case generator
Pick the component you are testing — a text field, a dropdown, a modal, a pagination control — and this writes the test cases for it. Positive, negative, boundary, edge case, invalid data, required, duplicate, role-based, multi-user, combination, workflow, sequence, concurrency, error handling, authentication, authorization, performance, compatibility, accessibility, security and recovery. Tick the types you want, press Generate, and download the lot as an Excel workbook.
The output is two axes multiplied together: the component you chose and the case types you ticked. That matters because not every pairing is real. A modal has no maximum-length boundary and a text field has no focus-trap case, so those pairings produce nothing rather than a row that reads like a test and checks nothing. A generator that filled in every cell would give you a longer list and a worse one, because somebody has to read it.
Boundary cases are always the three values around each edge, never just the edge. A field with a maximum of 50 characters gets 49, 50 and 51 — off-by-one is the most common validation defect there is, and it is completely invisible to a test that tries only a short value and a long one. Where a minimum and maximum sit close enough that the triples overlap, the duplicates are merged rather than emitted twice.
Edge cases and invalid data are kept apart, because confusing them produces the wrong fix. O'Brien, Zoë Müller, 李小龍 and an emoji are all correct values that a careless validator rejects — an apostrophe is not an attack and an accent is not a typo — so every edge case here expects the value to be accepted. Invalid data is the wrong kind of value altogether, and that is what expects rejection.
The security cases follow the same principle, and it is the one most test plans get wrong. An XSS payload should be accepted, stored, and then rendered inert — a field that refuses angle brackets cannot store "Bell & Co <Ltd>". Refusing input is not the same as escaping output, and a test case whose expected result says "rejected" teaches the developer to build the wrong thing. The payloads are the textbook ones for proving escaping and parameterisation, not filter-bypass polyglots.
Some case types need more than a component. Role-based, multi-user and authorization cases need the roles that can reach the screen; workflow and sequence cases need the states a record moves through. Where you have not supplied them, those checkboxes are disabled and say so, rather than producing a case that says "verify each role" and nothing else.
Every case carries an identifier, a scenario, its type, numbered steps, the test data and an expected result, with blank columns for actual result, status and comments. The identifiers are stable rather than random, so regenerating the same component produces the same IDs and a diff between two exports shows what actually changed. The workbook uses the same columns as the file-upload test cases elsewhere on this site, so both paste into one template.