Test case generator with edge cases

Name a feature, pick its type and list its fields. The test case generator builds a table of test cases with IDs, steps, test data and expected results, covering the happy path and the edge cases people forget. Export it as CSV or Markdown.

How to use the generated test cases

The generator writes test cases from patterns that catch real bugs in each feature type. Use the output as a starting point:

  1. Check the expected results. They describe sensible default behavior ("shows a clear error and keeps the other fields filled in"). Change them to match your actual requirements, such as the exact error message or the maximum length.
  2. Fill in limits. Where a case says "longer than the limit", put in your real limit so testers know exactly what to type.
  3. Prioritize. Mark the happy path and the cases touching money, accounts or data as must-run. Run edge cases when the feature changes.
  4. Import into your tool. The CSV opens in Excel, Google Sheets and Numbers, and most test management tools can import it. The Markdown table pastes into GitHub, Notion, Confluence or Linear.

Anatomy of a good test case

  • ID: a short, stable reference (TC-001) so bug reports can point to the failing case.
  • Scenario: what is being tested, in one line.
  • Steps: actions from a known starting point. Anyone on the team should be able to follow them.
  • Test data: the exact values to enter. Vague data ("an invalid email") leads to inconsistent testing; exact data ("anna@@example") is repeatable.
  • Expected result: observable behavior that is either clearly correct or clearly wrong.

The edge cases worth testing every time

Most bugs hide at the edges, not on the happy path. The generator includes these for each field:

  • Empty input and whitespace only, including leading and trailing spaces that look identical on screen.
  • Too long: one character over the limit, and a very long string to check that the layout doesn't break.
  • Special characters and emoji: apostrophes in names (O'Brien), accented letters, and emoji, which use more bytes and break some databases and length checks.
  • Code-like text treated as plain data: strings such as ' OR '1'='1 and <b>bold</b> should be stored and shown exactly as typed, never interpreted. If the text renders as bold or changes the result, that's a serious bug.
  • Wrong format: letters in a number field, a date like 31/02, an email without a domain.

And for the feature as a whole:

  • Double submit: clicking the button twice, or pressing Enter and clicking. It should create one record or one charge, not two.
  • Back button and refresh: after submitting, and in the middle of a multi-step flow.
  • Slow or lost connection: what the user sees, and whether they can retry safely.
  • Session expiry: submitting after being logged out in another tab.
  • Keyboard only and small screens: tab order, Enter to submit, and the layout at phone width with the keyboard open.

Positive, negative and edge cases

The table labels each case by type. Positive cases check that valid input works. Negative cases check that invalid input is rejected clearly, without losing what the user already typed. Edge cases check the boundaries and unusual situations: limits, odd characters, interruptions and repeated actions. A healthy set of test cases for a form usually has more negative and edge cases than positive ones, because that's where users get stuck and where data gets corrupted.

Test cases in a beta test

During a beta test, give human testers a handful of scenario-level cases and leave the long edge-case table to a systematic tester. Running 40 variations of a signup form is tedious for a person and easy to do inconsistently.

That's a good job for an AI beta tester. Paste the generated test cases as the task, and it runs each one in a real browser, records what happened, and reports failures as bugs with steps, screenshots and a recording.

Let an AI beta tester do it for you

An AI beta tester opens your website, web app, Android or iOS app or browser extension in a real browser or on a phone, signs up, clicks through every flow like a real user, and files bugs with steps, severity, annotated screenshots and recordings, then sends a report with a quality score.

Test case generator: FAQ

What is a test case?

A test case is a single, repeatable check: a scenario, the steps to perform, the test data to use and the expected result. A failed test case becomes a bug report.

What test cases should every form have?

The happy path, each required field left empty, invalid formats, too-long input, special characters and emoji, code-like text stored as plain text, double submit, back button after submit, and behavior on slow connections and small screens.

How do I describe fields?

One field per line, with an optional type and “required”, like “Email (email, required)” or “Age (number)”. Supported types include text, email, password, number, phone, date, url and file. Unknown types are treated as text.

Why are SQL-like strings in the test data?

They check that the app treats user input strictly as data. A string like ' OR '1'='1 should be saved and displayed exactly as typed. It is plain text for a normal user-level test, not an attack tool.

Can I import the CSV into a test management tool?

Yes. The CSV has one row per test case with ID, type, scenario, steps, test data and expected result columns, which most spreadsheet and test management tools can import or map.

Is my feature description uploaded?

No. Test cases are generated in your browser and nothing is sent to a server.

More free beta testing tools

Related beta testing guides