> ## Documentation Index > Fetch the complete documentation index at: https://www.testmuai.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Test Generation and Exploration Use Cases > Test generation and exploratory testing use cases for Kane CLI: generate test cases from a description, from a screenshot or a spec, design a requirement-linked suite from a PRD, and explore an app to map its screens and design tests. Writing a test is the second problem, and deciding what to test is the first. These use cases cover the design side of Kane CLI: turning a sentence, a screenshot, or a requirements document into test cases, linking each test to the requirement it proves, and letting Kane CLI explore an app to find the flows nobody has written tests for yet. Every path on this page ends in runnable `_test.md` files, so the cases you design here run with `kane-cli testmd run` and `kane-cli testrun run` like any other test. ## Generate test cases from a description [AI test case generation in Kane CLI](https://www.youtube.com/embed/5H1PtVG2Ke4) A one-line description of a feature is enough for Kane CLI to propose scenarios and test cases, each tagged positive, negative, or edge with a priority. This use case goes from a description to saved, runnable tests in three commands. 1. Generate from a description, for example `kane-cli generate "checkout flow on a shopping site"`. The command prints a request ID when it finishes. 2. Read the scenarios and cases, and refine them in natural language as many times as you need, for example `kane-cli generate "also cover an expired card and an out-of-stock item" --refine --req `. 3. Save the functional cases as `_test.md` files with `kane-cli generate --save --req `. Kane CLI writes them to `.testmuai/tests///_test.md`. 4. Run a saved case with `kane-cli testmd run _test.md`, or the whole folder with `kane-cli testrun run --match '^.testmuai/tests//'`. See [Generate Test Cases](https://www.testmuai.com/docs/docs/kane-cli-generate.md) for the three modes and every option. ## Generate test cases from a screenshot or a spec A screenshot of a design or a page of a spec carries details a one-line description leaves out. In this recording, a screenshot of a sign-up page is attached to a generate request, and Kane CLI returns two scenarios, one for email, Google, and GitHub sign-up and one for input validation, with three cases each, which are then saved as runnable tests. 1. Attach files to a new generation with `--files`, for example `kane-cli generate "Generate test cases for this signup page covering email signup, Google auth, GitHub auth, and the login link" --files ./register-page.png`. 2. Attach up to ten files of 50 MB or less, including PDFs, Word documents, spreadsheets, images, audio, and video. 3. In the interactive TUI, type `@` in the generate prompt to attach a file inline. 4. Open a case to read its priority, preconditions, test data, and steps, and remove the cases you don't want. 5. Save the rest with `kane-cli generate --save --req `. Files attach to a generation or a refine, not to a save. ## Design a requirement-linked suite from a PRD A suite that cannot say which requirement each test proves is hard to trust and harder to maintain. In this recording, Kane CLI reads a bank app's requirement document, proposes four use cases, designs scenarios and tests for one of them, runs them, and shows in the evidence viewer which acceptance criteria each passing test verified. 1. Snapshot your requirement documents with `kane-cli context ingest`. 2. Run `kane-cli context extract`. An agent reads the sources and proposes use cases, citing the lines it read. 3. Review the proposals with `kane-cli context review`, and promote the ones you agree with to trusted. 4. Design tests for one use case with `kane-cli design tests`, which writes acceptance criteria, scenarios, and one `_test.md` per scenario, each tagged with the criteria it verifies. 5. Approve the design output with `kane-cli context review`, then run the tests with `kane-cli testmd run` or `kane-cli testrun run`. 6. Run `kane-cli cover` to see what the evidence pack proved and what the design still owes. 7. When a requirement document changes, run `kane-cli maintain` to bring the suite back in line. See [Assurance](https://www.testmuai.com/docs/docs/kane-cli-assurance.md) for the loop, the vocabulary, and what costs credits. ## Explore an app and design tests from what it finds Exploratory testing finds the screens and flows that a written suite never mentions. `kane-cli explore` runs on the cloud grid, maps the screens, flows, and findings it reaches, and designs tests from that map into your Test Manager project. 1. Start with a read-only exploration, so nothing in your app is changed: ```bash theme={null} kane-cli explore run --project \ --url https://staging.your-app.com \ --prompt "Explore sign-up, the dashboard and the settings pages" \ --policy read_only \ --max-leases 40 ``` 2. Always pass `--project`, and pass `--policy read_only` on every run that must not change data, because each run starts from the default `mutating` policy. 3. Watch the live view for the number of screens, flows, and findings as they grow. Press Ctrl+C to detach, and the exploration keeps running on the grid. 4. Open the map with `kane-cli explore view --project ` to see the screens and flows it found. 5. Move the tests it designed into a folder and run them like any other suite. For an app behind a login, on localhost, or on a private network, see [Exploration](https://www.testmuai.com/docs/docs/kane-cli-exploration.md#an-app-behind-a-login). ## Watch for product bugs while tests are authored The first run of a new test is the moment Kane CLI sees the page for the first time, which makes it a good time to notice a product bug. Bug detection asks the agent to flag suspicious behaviour while it authors steps, and Kane CLI confirms or rejects each suspicion. 1. Run new or generated tests with `--bug-detection continue`, so confirmed bugs are recorded and the run keeps going. 2. Read the confirmed bugs in the run result and the evidence pack, each with the step where it was found. 3. Switch to `--bug-detection stop` when a confirmed bug should end the run. See [Bug detection](https://www.testmuai.com/docs/docs/kane-cli-configuration.md#bug-detection). ## Next steps * [Generate Test Cases](https://www.testmuai.com/docs/docs/kane-cli-generate.md): modes, options, and the shape of a result * [Assurance](https://www.testmuai.com/docs/docs/kane-cli-assurance.md): requirement-linked design, coverage, and maintenance * [Exploration](https://www.testmuai.com/docs/docs/kane-cli-exploration.md): policies, sign-in, private apps, and the map * [Regression & E2E Testing](https://www.testmuai.com/docs/docs/kane-cli-regression-e2e-testing.md): keep the generated tests running on every build ## Terminal First Testing With Kane CLI Natural language browser & mobile app tests right from terminal. Book a Demo ![Kane CLI terminal](https://assets.testmu.ai/resources/images/Terminal-KaneCLI.png) × Schedule Your Personal Demo
Select Product Schedule Demo
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.