The AI Test Case Generator
Test design is usually the first time anyone reads the acceptance criteria closely, and the moment their gaps come out. This agent reads the story from Jira or the work item from Azure DevOps, drafts test cases with steps, data and expected results, names the criteria it could not test, and writes to Jira only after QA approves.
What is an AI test case generator?
An AI test case generator is a governed agent that converts user stories and acceptance criteria into executable test cases with preconditions, steps, test data and expected results. It reads requirements from Jira and Azure DevOps, covers positive, negative and boundary paths for each criterion, flags criteria too vague to test, and writes to Jira only after QA approval.
What it does
What it is not
Acceptance criteria are written in minutes and tested for days
Stories reach a sprint with criteria written by someone picturing the happy path. Turning them into test cases means inventing the boundaries, the invalid inputs and the expected messages by hand for every story, and the cases that get dropped under deadline are precisely the ones production finds first.
Criteria are too vague to run
A line such as “handles errors gracefully” cannot be executed until someone decides which errors, and what graceful means.
Negative paths get dropped
Invalid, empty and boundary cases take longer to write than the happy path, so they are the first thing cut when time runs short.
Coverage is asserted, not shown
Linking every case back to the criterion it verifies is tedious, so nobody can say which criteria have no test at all.
Requirements live in two trackers
Some teams plan in Jira and others in Azure Boards, and copying stories between tools is where wording quietly drifts.
Cases drafted from the criteria, checked by the people who run them
Coverage
One Criterion, Several Cases
Happy path, boundaries, invalid input.
Each acceptance criterion is expanded into the cases needed to show it holds: the expected path, values on either side of every limit, empty and malformed input, and permission variations wherever the story mentions roles. Every case carries a reference to the criterion it verifies.
- Positive, negative and boundary cases
- Preconditions and test data stated
- An expected result for every step
- Criterion reference on each case
Coverage you can show
Sources
Jira And Azure DevOps As Inputs
Read where the requirements already live.
Stories, linked defects and earlier test issues are found by meaning in your indexed Jira projects, while Azure DevOps Services work items are read by project, id or query. Azure DevOps stays read-only, so approved cases for those teams come back as an Excel workbook.
Workbook hand-off
Review
Written Back Only After QA Approves
A test lead signs off first.
Drafted cases wait behind an approval request. Once a QA lead accepts them, the agent can create them as Jira issues of the type your project uses for tests and comment on the story with what was added, so the trail from requirement to case sits on the ticket itself.
Jira issues and comments
How the AI Test Case Generator runs a task
- STEP 01
Pull the requirement
The story is located in your indexed Jira projects by meaning, together with linked defects and earlier test issues, or the Azure DevOps work item is read directly by project, id or query. Acceptance criteria are separated from the description so each one can be tested on its own.
Jira semantic searchWork item read - STEP 02
Question the criteria
Criteria that cannot be executed as written, such as an unstated limit, an undefined error message or a role mentioned but never described, are listed as questions for the product owner. The agent does not settle an ambiguity by guessing what the author probably meant.
Ambiguity checkOpen questions - STEP 03
Design the cases
Each criterion becomes the set of cases needed to show it holds: the expected path, values just inside and outside every limit, empty and malformed input, and permission variations. Preconditions, test data and an expected result are written for every step of every case.
Boundary valuesNegative pathsTest data - STEP 04
Package for review
The full set is assembled into an Excel workbook with one row per step and a column tying each case to its criterion, which gives the QA lead a single place to edit, delete or add cases before anything is written into a tracker.
Excel workbookCriterion mapping - STEP 05
Write back after approval
An approval request pauses the agent until a QA lead accepts the set. For Jira, approved cases are then created as issues of the type your project uses, and a comment on the story records what was added. Azure DevOps remains read-only throughout.
QA approvalJira issue creationStory comment
Systems the AI Test Case Generator connects to
Requirements
Test design
Inputs, outputs and runtime
- Ingests
- Jira user storiesAzure DevOps work itemsAcceptance criteriaLinked defectsTeam test conventions
- Produces
- Test cases with steps and dataExpected result per stepCriterion-to-case mapExcel workbookQuestions on vague criteria
- Triggered by
- Story marked readySprint planningDefect resolved
- Human oversight
- A QA lead approves before any Jira write
- Models
- Any connected LLM or SLM, self-hosted on-prem
- Typical latency
- Minutes per story
- Deployment
- On-premise or private cloud
- Data residency
- Story text processed inside your environment
Where an AI test case generator saves the most time
Sprint Test Design
Draft cases for every story entering a sprint, so testers begin by reviewing instead of writing from a blank page.
Acceptance Criteria Review
Expose criteria too vague to test and return the questions to the product owner before development starts.
Regression Case From A Fixed Bug
Draft the manual check that would have exposed a resolved Jira defect, so the scenario is retested in later releases.
Azure DevOps Test Preparation
Read a feature’s work items and produce a reviewed workbook of cases for the team to load into its own test tooling.
UAT Scripts
Write business-readable acceptance scripts that end users can follow step by step during user acceptance testing.
Test Data Planning
List the values each case needs, including boundary and invalid ones, so data is prepared before execution day.
AI Test Case Generator vs chatbots and SaaS copilots
A model asked for test cases will write the obvious ones fluently, and the obvious ones are the checks a developer already ran before opening the pull request.
| Generic chatbot | SaaS copilot | VDF AI | |
|---|---|---|---|
| Requirement source | Pasted text | The ticket in view | Jira and Azure DevOps, read directly |
| Case depth | Happy path | Happy path, some errors | Positive, negative and boundary |
| Vague criteria | Guessed | Guessed | Raised as questions |
| Test data | Rarely specified | Sometimes | Stated for every case |
| Traceability | None | Partial | Every case to its criterion |
| Writes to trackers | Not possible | Varies by product | Jira only, after approval |
| Where backlog text goes | Vendor service | Vendor cloud | Stays in your environment |
Governance and controls
An approved test case is a statement about what the software must do, and the suite quietly becomes the working definition of done, so nothing the agent drafts joins it until a tester has accepted it.
QA approval before write-back
No Jira issue created without sign-off
Azure DevOps kept read-only
Work items are read, never changed
Every case traced
Criterion reference on each case
Ambiguity surfaced
Vague criteria returned as questions
Role-based tool access
Admins assign the tools it may call
Agent activity logged
Reads, drafts and writes are audited
Evidence it leaves behind
What test teams notice after rollout
Who runs the AI Test Case Generator
QA lead
Starts each sprint reviewing a drafted case set with the negative and boundary paths already written, and spends the hours saved on the exploratory testing that no generator can do for the team.
Product owner
Receives a short list of acceptance criteria that could not be tested as written, early enough in the sprint to fix the wording before a developer builds something against the ambiguity.
Delivery manager
Can see from the comment on each story which acceptance criteria have test cases against them, instead of relying on a coverage percentage reported at the end of the sprint.
Questions about the AI Test Case Generator
What is an AI test case generator?
It is an agent that turns requirements, user stories and acceptance criteria into structured test cases with preconditions, steps, test data and expected results. VDF’s version reads stories from Jira and work items from Azure DevOps, traces each case to the criterion it verifies, and writes to Jira only after a QA lead approves.
How is an AI test case generator different from a generic chatbot?
A chatbot produces test ideas for whatever story text you paste into it. This agent fetches the story and its linked defects itself, expands every criterion into positive, negative and boundary cases, flags criteria that cannot be tested as written, and puts approval before any write.
Can an AI test case generator run on-premise on Jira and Azure DevOps data?
Yes. Backlogs describe unreleased features, security fixes and customer commitments, and the agent processes them on infrastructure you control. Jira content is searched from your own index, and Azure DevOps reads use the Microsoft authorisation your tenant has already granted.
What does an AI test case generator produce, and in what format?
Test cases with a title, preconditions, numbered steps, test data and expected results, each referencing its acceptance criterion; an Excel workbook of the set; a list of untestable or ambiguous criteria; and, after approval, Jira issues plus a comment on the story.
Where does an AI test case generator fit in a governed AI programme?
It drafts; testers decide. A QA lead approves cases before they are written anywhere, execution stays with your testers and pipelines, and automated test code belongs to the AI Software Testing Agent.
Can it create test cases directly in Jira?
Yes, after approval. Drafted cases are reviewed first, then created as Jira issues using the issue type and fields your project uses for tests, and the agent adds a comment to the source story listing them. If your team keeps test cases in a separate test-management tool rather than as Jira issues, the Excel workbook is the hand-off instead.
Does it work with Azure DevOps Test Plans?
It reads Azure DevOps Services work items, including the acceptance criteria on a user story, but it never writes to Azure DevOps. Approved cases arrive as an Excel workbook for your team to import with whatever method its test tooling supports. On-premises Azure DevOps Server and TFS connect through the platform’s separate TFS connector rather than this one.
How is this different from the AI Software Testing Agent?
They work at different layers. The software testing agent lives in the repository, writing automated test code against behaviour and triaging pipeline failures. This agent works on requirements, producing human-readable test cases from stories for testers, product owners and acceptance testing. Teams often use both, with the testing agent writing automated tests for the reviewed cases worth automating.
Which test design techniques does it apply?
Mainly equivalence partitioning and boundary values for inputs with limits, negative testing for invalid and missing data, and role variations where a story mentions permissions. It does not attempt every combination: when a criterion has many interacting inputs, it points out the combination problem to the QA lead instead of listing every permutation.
Can it write test cases in Gherkin (Given/When/Then)?
Yes, if your team writes acceptance tests that way. Ask for Given/When/Then and each case becomes a scenario with the precondition, action and expected outcome in those clauses, still linked to the criterion it verifies and still subject to QA approval before anything is created in Jira.
Give your testers a reviewed first draft for every story
See the AI Test Case Generator turn a Jira story into approved test cases.