AI test case generation that ends in a running test
Most AI test case generators hand you a title, a list of steps and an expected result. Someone still runs it by hand before the release. BuniOD starts from the same plain-language steps and returns a scenario that runs against your live web app, in a real browser, on a schedule you set.
You write the steps. BuniOD matches them to the page, adds the checks, and waits for your confirmation before anything runs.
1. Click the 'Sign in' button.
2. Fill in the email from the test identity 'Agent Brown'.
3. Fill in the password from 'Agent Brown'.
the order 'ACME-1001' is shown with the status 'Delivered'
What an AI test case generator produces
An AI test case generator writes test cases from a description of a flow instead of from a test script. The output is usually a document: an identifier, a title, preconditions, numbered steps, the test data to use, and an expected result — ready to paste into Jira, Azure DevOps, TestRail or a spreadsheet.
That output has real value. A written test case is easier to review, easier to hand to a colleague, and easier to keep as a record of what the team agreed to check. What it does not do is run. The steps still have to be carried out by a person, in a browser, before every release — and the more releases there are, the more often that person repeats the same clicks.
BuniOD takes the same starting point — a flow written in plain language — and ends somewhere else. The output is a scenario: a browser test that BuniOD executes against the app you connected.
Test case text versus a test that runs
Both formats begin with steps a person can read. The difference is what happens after the expected result is written.
| Generated test case text | A confirmed BuniOD scenario | |
|---|---|---|
| What you get | A document with a title, numbered steps, test data and an expected result | A scenario that runs in a browser against your live web app |
| Who executes it | A person, by hand, every time | BuniOD, in headless Chromium, on demand or on one daily schedule |
| Where it lives | Pasted into Jira, Azure DevOps, TestRail or a spreadsheet | In BuniOD, next to its run history |
| When the interface changes | The written steps drift out of date and someone re-checks them by hand | BuniOD re-matches the element and saves the new location after a passing run |
| What a failure gives you | A note from whoever ran it | Screenshots, console and network logs, and a plain-language explanation of what failed |
| What you need to write it | A clear description of the flow | The same description — no scripts, no selectors, no page objects |
Neither column wins in every situation. If the deliverable has to be a test case record inside your issue tracker, a text generator produces that document and BuniOD does not.
From one manual test case to a running test
Take the test you ran by hand before the last release and walk it through the product. This is the whole path, using an order search as the example.
Connect the app
Add the web app by its URL. Staging or production both work; staging is the safer choice, because scenarios can create and change test data. Public pages need only the URL. A signed-in app is reached through HTTP basic auth or a test identity.
Write the steps you already know
Write the flow as numbered plain-language steps, the way you would brief a manual tester: the exact button and field labels, the values to type, the waits after slow actions, and a "Confirm ..." check where the page should have changed. Keep the expected result separate from the steps.
Click the 'Sign in' button. Fill in the email from the test identity 'Agent Brown'. Fill in the password from 'Agent Brown'. Click 'Log in'. Confirm you see 'Dashboard'. Open 'Orders'. Type 'ACME-1001' in the search field. Wait for 3 seconds. Confirm you see the order 'ACME-1001'.
the order 'ACME-1001' is shown with the status 'Delivered'
Review what comes back
BuniOD's AI matches each step to the live page, adds the checks, and returns a scenario. Read it as you would read a test case a colleague wrote. If a value or a step is wrong, edit its input values or regenerate the scenario.
Confirm it
Nothing runs until you confirm. Only confirmed scenarios are included in runs.
Run it and read the result
Confirmed scenarios run on demand and on one daily schedule. Every run keeps screenshots, console and network logs, and a plain-language explanation of what failed and at which step.
When the interface changes, BuniOD self-heals the locators: it re-matches the element on a later run and saves the new location once that run passes.
The full sequence, including what the AI records during a run and what you can change at review, is described on How BuniOD works.
If the test case started life as an acceptance criterion, turning acceptance criteria into automated tests covers how the wording maps onto steps and checks.
How to write steps that run reliably
The step list is what decides whether the scenario runs. Write it the way you would brief a manual tester who has never seen the app.
Name the label that is on the screen
'Sign in', 'Log in', 'Orders', 'ACME-1001' — the words in the interface, not a paraphrase of them.
Point at a test identity instead of describing credentials
"Fill in the email from the test identity 'Agent Brown'" keeps the values with the identity, and the identity has its own inbox.
Check between steps
"Confirm you see 'Dashboard'" right after login tells you which step broke when a run fails, rather than only that the run failed.
Wait where the app is slow
"Wait for 3 seconds" after a search or a save lets the next check read a settled page instead of a spinner.
Keep one expected result outside the steps
The steps say what to do; the expected result states the single condition that makes the test pass.
Attach the file for upload steps
An upload step needs the file attached to the step, not described in the sentence.
Use a dedicated test account and non-production data
Scenarios can create and change records, so keep real customer data out of the test identity.
Getting the wording right is most of the work; how to write prompts for test generation walks through the phrasing in detail.
When BuniOD is not the right fit
These limits are worth reading before you sign up.
API testing
BuniOD drives a browser. It does not call endpoints or assert on response bodies.
Native mobile apps
BuniOD tests desktop web apps. Native mobile testing is in development and not available today.
Cross-browser coverage
Runs use headless Chromium at a desktop viewport. Firefox, Safari and mobile browsers are not covered.
Test cases that must live in Jira, TestRail or Azure DevOps
BuniOD does not export test cases to those tools. A confirmed scenario stays in BuniOD and runs there.
Pipeline gating and chat alerts
There is no CI/CD trigger, no Jira, GitHub or Slack integration and no public API. Runs happen on demand and on one daily schedule.
Questions before you start
Does BuniOD export test cases to Jira or TestRail?
Does the AI write the test steps for me?
What does a scenario actually run in?
Can it test a flow behind a login?
Can it check the emails my app sends?
How often do scenarios run, and what do I get when one fails?
Do I need to write scripts, selectors or page objects?
Does it test APIs or mobile apps?
Start with one manual test case
Pick the test you run by hand before every release. Write its steps, review the scenario BuniOD returns, confirm it, and let it run against staging. You will know quickly whether the output fits the way your team works.