Writing test cases by hand is the slowest part of QA. Cycluno's AI test design turns a PRD — uploaded as a PDF, pasted as text, or fetched from a link — into a structured set of features, requirements and test cases in minutes. This guide explains exactly what the AI does at each step.
1. How the AI extracts requirements
When you add a product, Cycluno sends your PRD to the AI with the instructions of a senior QA lead. It doesn't summarise the document — it mines it for everything testable:
Your PRD
PDF, pasted text or a link
Feature extraction
Distinct, testable features with priorities
Requirements
3–8 rules per feature: validation, errors, limits, permissions
Acceptance criteria
2–6 measurable checks per requirement
Test cases
Steps + expected results, grouped by feature
- Features — every distinct, testable product feature, with a concise title, a 1–2 sentence description of expected behaviour, and a priority (high, medium, low).
- Requirements — each feature is broken into 3–8 testable rules: functional behaviour, validation, error handling, permissions, limits, states, integrations and non-functional needs.
- Acceptance criteria — each requirement gets 2–6 specific, measurable criteria covering the happy path, validation, errors and boundaries.
- Surfaces, objectives and scope — the AI identifies which platforms the product exposes (Web, Mobile, API, Database, Desktop), drafts 3–6 test objectives, and writes down what is in scope and out of scope for testing.
- Gap questions — requirements that are missing or ambiguous come back as short questions for the product owner (for example, "What should happen after 5 failed login attempts?"), so gaps surface before testing starts, not after a production bug.
Everything the AI extracts is a draft: your team reviews, edits and approves features and cases before any run. The AI proposes; you decide.
2. PRD to test case, end to end
Here is a real-shaped example. Given this line in a PRD:
Cycluno extracts the Password Reset feature with three requirements, and generates cases like these:
| Requirement | Generated test case | Pattern |
|---|---|---|
| Reset via email | Request reset link with registered email → email with a signed link arrives within 2 minutes | Happy path |
| Link expires after 60 minutes | Open a 61-minute-old link → 'Link expired' page offers a fresh request | Boundary |
| Password rules: 8+ chars, one number | Submit '12345' as the new password → validation error lists the rules, form not submitted | Validation |
| Reset via email | Request a reset for an unregistered email → same confirmation shown, no account hint leaked | Security |
One sentence in the PRD became four executable tests — including a security case the original sentence never mentioned. Here is what the Design tab looks like in the app:
3. Patterns and templates
Every generated case follows a small set of proven patterns. Knowing them makes reviews fast — you recognise the shape and only check the specifics:
Happy path
The feature works as intended with valid input. Every feature gets at least one.
Sign in with valid email and password → dashboard loads.
Validation
Each input rule becomes its own case: required fields, formats, lengths.
Reject an email without '@' with an inline error.
Negative / error handling
The failure path must fail gracefully and preserve user data.
Declined card → clear message, cart contents preserved.
Boundary
Limits from the PRD are tested at, just below and just above the line.
5 failed logins allowed → the 6th attempt locks the account.
Permissions
Every role mentioned in the PRD gets allowed and denied variants.
A viewer can open the report but cannot edit test cases.
State & lifecycle
Draft → published → archived style flows get a case per transition.
An archived product no longer accepts new runs.
Integration
Anything the PRD says 'sends', 'syncs' or 'notifies' gets an end-to-end check.
Failed payment → notification email arrives within 5 minutes.
Each case itself follows one template: title, priority, preconditions, numbered steps, and a single expected result. One idea per case — so when a run fails, the failure points at exactly one broken behaviour.
4. Edge cases the AI looks for
Beyond what the PRD says outright, the AI is instructed to probe the places where software usually breaks:
| Edge case | What the generated test checks |
|---|---|
| Double submission | Clicking Pay twice must create exactly one order and one charge. |
| Empty and whitespace input | Empty search, spaces-only names, blank forms — never an error page. |
| Special characters & injection | Search for %'; DROP TABLE-- must render safely with the input escaped. |
| Expiry and timing | Reset links expire, sessions time out, rate limits kick in — each tested at the boundary. |
| Concurrency | Two users buying the last item in stock — only one order succeeds. |
| Large input | Files just over the size limit, 10,000-row lists, very long names. |
| Interrupted flows | Closing the browser mid-checkout, losing connection during upload. |
| Cross-account isolation | User A's API responses must never contain user B's data. |
When the PRD doesn't specify the behaviour — say, no lockout policy for failed logins — the AI doesn't invent a test with a made-up expectation. It raises a gap question instead, and the case is written once you answer.
5. Download a sample
Want to see the output format before connecting your own PRD? Download a sample of 20 generated test cases for a typical web shop — covering sign-in, password reset, checkout, search, profile, API and notifications, in the same CSV format Cycluno exports from the Design tab:
20 cases · opens in Excel, Google Sheets or any test management tool