Generative AI-Based Testing Certification

Your Progress: out of 28

AI-Driven Test Case Generation with testRigor

This section of the certification course focuses on how to use AI to generate automated test cases efficiently and effectively in testRigor. You will learn multiple ways to generate tests – from broad, platform-level creation to highly granular, test-case-specific workflows – so you can choose the approach that best fits your team’s maturity, documentation quality, and goals.

Learning Objectives

• Generate test cases using AI when creating a new test suite
• Generate additional test cases inside an existing test suite
• Use feature descriptions, wireframes, and designs to improve AI output
• Generate tests at a granular, single-test-case level
• Separate succinct test case names from detailed AI context
• Understand common failure points and how to correct AI-generated tests

Generating Test Cases When Creating a Test Suite

When creating a new test suite, testRigor allows you to use AI to generate an initial set of test cases based on the description of the platform/application that you intend to test. Since we already know how to create a test suite, this section focuses on how to create the best descriptions to generate meaningful scenarios.

Step 1: Provide a Platform Description

The platform description gives AI high-level context about what it is testing. testRigor has already trained its AI on prompting logic so that users only need to worry about clear descriptions of their applications at this stage.

• Clearly state the type of application (e-commerce, SaaS, internal tool, etc.)
• Describe the application’s general abilities, especially things that make it unique
• Mention what users commonly do on the application (search, checkout, reporting, etc); differentiating logged-in vs guest user flows helps
• Explicitly call out areas that are critical to the business

Important note: As a rule of thumb, remember that AI cannot guess what matters most concerning you and your company’s quality and coverage goals. If something is important, it must be stated.

This has every component of a good prompt, and should get very detailed test case suggestions, which will serve as prompts for the actual test cases that AI will generate.

Step 2: Select the Number of Test Cases and Review AI Test Case Name Suggestions

After inserting your app description, choose how many test cases AI should generate. This defines the breadth of coverage, not test quality.

Next, click the “Create Test Suite” button Before generating tests. testRigor will create the suite, AI will propose test case name suggestions.

• These names act as prompts for test generation
• Users can edit, regenerate, or remove any suggestion

For this method, AI depends solely on the test case names for the steps that it will create, so more detailed prompts do translate into better AI deductions. However, detailed test case names may not be the best for tracking, so remember that there are other methods that may better suit your company’s needs.

When the app description is the only input for AI to rely on, this level of detail in the output on the test case level is ideal. However, if this seems too descriptive, remember that it is only the first method of AI generation, and there may be another method that works better for you.

Step 3: Generate and Review Tests

• Start from common flows (e.g., login or homepage navigation)
• Progress step-by-step using visual context from screenshots

AI output is rarely perfect on the first pass. The goal is to reduce manual effort, not eliminate review. Think of this as AI doing the heavy lifting, while you fine-tune the final result.

1. Check the cases that have passed to ensure the scenarios are logically following the flows suggested in the test case names.
2. Make changes to polish and stabilize the test cases as needed. These changes might include the following:
   • Create re-usable rules out of steps that will frequently be repeated.
   • Eliminate unnecessary steps and sequences.
   • Address timing issues that built-in waits foreseeably will not cover. In other words, if you know there are steps would plausibly take longer than the default wait timeout in your testRigor settings (Settings -> Speed Optimizations -> Timeouts And Delays), either change the default settings (only recommended if the timing issue will affect most or all of your test cases) or address them in your script.
3. For cases that fail, fix the step it failed on and try to finish creating the flow using AI by clicking the Use AI to complete creating this test case button.
4. Repeat this process or polish the cases using our plain-English steps if AI struggles too much.

If the test case descriptions given by AI upon creating the suite are detailed well enough but you are not a fan of long test case names, a viable alternative after the initial triggering of the cases could be to copy the descriptions into the AI context and edit the test case description/name to be more concise.

Common Mistakes During Test Case Generation Via App Description

Writing vague platform descriptions

This type of description will get generic and likely un-meaningful scenario suggestions and test cases. We are the masterminds behind our test plan.

Assuming AI knows business priorities

The most common mistake is perhaps assuming that AI knows what is meaningful to your business. It can understand what you tell it to do, but can’t make assumptions based on internal decisions. Mention critical user flows in your description to increase AI’s ability to produce useful cases.

Expecting perfect tests on the first run

Even when everything is done according to the suggestions, AI can fail for several reasons; so don’t expect perfect cases on the first execution. There could be missing or ambiguous platform context, multiple valid user paths, UI elements that look similar but behave differently – that’s only to name a few.

Be prepared to guide it when it goes off course. Even cases that pass on the first attempt likely need to be polished. Remember that the point is for AI to do the heavy lifting. The case suggestions that it provides can’t account for the nuances that may be encountered during the flow.

Generating Test Cases Inside an Existing Test Suite

AI can also be used to expand coverage after a test suite already exists.

Update AI Settings

In Settings -> AI, users can make several decisions on AI behavior:

• Update the application description. If you create a suite without adding the app description, this is where you can do it.
• Upload images such as wireframes or design mockups

This description follows the same best practices as test suite creation.

Generate Tests from a Feature Description

Instead of describing the entire platform, users can generate tests for a specific feature.

1. Go to the Test Cases section
2. Click Generate test cases based on feature description
3. Describe the feature clearly and unambiguously
4. Select how many test cases to generate
5. Edit or remove suggested test case names

This approach is ideal for new features or targeted coverage.

Common Mistakes (Feature-Level Generation)

• Describing features too broadly
• Forgetting edge cases or alternate paths
• Overloading the feature description with unrelated behavior

Why AI Fails Here

• Feature boundaries are unclear
• Visual context is missing
• Expected results do not align with visible next actions

Update AI Settings

In Settings -> AI, users can provide general information and visual context that AI can use when generating test cases for the suite.

• Add or update the application description. If you created the suite without an app description, this is where you can add it.
• Upload images such as wireframes, diagrams, design mockups, or screenshots.

The application description should follow the same best practices used during test suite creation: begin with general information about the application, then explain its important features, common user activities, and business-critical workflows.

Visuals uploaded in the AI settings provide additional context about the application and can be used when AI generates test case suggestions.

Generate Tests from a Feature Description

Instead of describing the entire platform, users can generate tests for a specific feature.

1. Go to the Test Cases section.
2. Click Generate test cases based on feature description.
3. Select how many test cases you want AI to generate.
4. Describe the feature clearly and unambiguously.
5. Optionally attach wireframes, diagrams, designs, screenshots, or other images that provide visual context about the feature.
6. Click Generate.
7. Review the suggested test cases.
8. Edit, regenerate, or remove suggestions that do not accurately represent the intended coverage.
9. Select the test cases that you want testRigor to finalize and generate as full test steps.

The resulting test steps are generated using testRigor’s English-like syntax and can be reviewed and edited after generation.

• Generating coverage for a new feature
• Adding tests for a specific area of an existing application
• Creating tests from requirements and designs before all coverage has been written manually
• Expanding coverage without generating another complete set of platform-level tests

Common Mistakes (Feature-Level Generation)

• Describing features too broadly
• Forgetting edge cases or alternate paths
• Overloading the feature description with unrelated behavior
• Assuming that attached visuals explain business rules or expected results

Why AI Fails Here

• Feature boundaries are unclear
• The feature description does not explain the intended behavior
• Important visual context is missing
• Expected results do not align with the actions described

Section 3: Using Visuals (Wireframes, Designs, Images)

Wireframes, diagrams, design mockups, screenshots, and other images can be used to provide AI with additional visual context.

Visuals can be uploaded in Settings -> AI to provide context about the application. They can also be attached while using Generate test cases based on feature description when they relate to the specific feature being described.

How Visuals Help AI

• Understand the general layout of a screen
• Identify visible fields, buttons, menus, links, and other interface elements
• Understand how different areas of the interface are organized
• Infer which actions may be possible on each screen
• Infer likely navigation paths between screens
• Generate test case suggestions that are more closely related to the intended design

For example, a feature description might explain that a user needs to submit an expense reimbursement request. Wireframes could additionally show that the workflow contains separate screens for entering expense details, uploading a receipt, reviewing the request, and confirming the submission.

The wireframes help AI understand how the workflow is organized. The written description must still explain what the user is expected to accomplish and what results should be verified.

Visuals Do Not Replace the Feature Description

A visual can show that a field, button, or screen exists, but it may not explain how the feature is expected to behave.

• Which fields are required
• Which values are valid or invalid
• Which users or roles can perform an action
• What calculations should occur
• What information should be saved
• What error messages should appear
• What should happen after an action is completed
• Which alternate paths or edge cases are important

These details should be included in the feature description.

Important note: AI can use visible information to make better deductions, but it cannot reliably determine internal business requirements from the appearance of a design. If a behavior is important to the test, describe it explicitly.

Writing a Description to Accompany Visuals

• The purpose of the feature
• Who uses the feature
• Where the workflow begins
• How the user moves between screens
• Which actions the user should perform
• What the expected results are
• Which validations, permissions, or business rules apply
• Which alternate paths or errors should be tested

The description does not need to repeat every visible detail from the wireframes. It should explain the meaning and expected behavior behind those details.

The wireframes help AI understand the visible screens, controls, and intended navigation. The description supplies the validation rules and expected results that cannot be determined from the images alone.

Using Multiple Wireframes or Images

When uploading several images, explain how they relate to one another.

• The first image shows the starting page.
• Clicking Create Request opens the form shown in the second image.
• Clicking Continue opens the review screen shown in the third image.
• Submitting the request opens the confirmation screen shown in the fourth image.

This provides AI with the intended order of the screens and reduces ambiguity when several navigation paths may be possible.

If the images represent different user roles, application states, or alternate flows, identify those differences in the feature description.

Reviewing Suggestions Generated with Visual Context

• Confirm that each suggestion represents a meaningful scenario.
• Remove suggestions that repeat the same behavior.
• Edit suggestions that misunderstand the intended workflow.
• Add important scenarios that AI did not suggest.
• Confirm that business-critical positive, negative, and alternate paths are included.

The selected suggestions are used to generate the full test steps. Correcting the suggestions before finalizing them helps prevent AI from generating the wrong workflow.

Common Mistakes (Visual Context)

Uploading visuals without explanation

AI may identify visible interface elements but still misunderstand what the user is expected to accomplish. Always include a written feature description.

Describing only what is already visible

A description such as “The screen contains an Amount field and a Submit button” adds little information when those elements are already shown in the wireframe.

Use the description to explain behavior, rules, expected results, and the purpose of the workflow.

Assuming AI understands business rules from the design

A design may show a form, but it usually does not explain field requirements, permissions, calculations, error conditions, or status changes. Include these details explicitly.

Providing multiple screens without explaining their order

Several actions may be possible from the same screen. Explain which action leads to the next image and which user path should be tested.

Expecting perfect tests from visuals alone

Visuals give AI more context, but human review is still required. Suggestions may be incomplete, repetitive, or based on an incorrect interpretation of the intended workflow.

The purpose of visual context is to give AI better information and reduce the amount of work required to create useful test cases. It does not eliminate the need to review and refine the generated output.

Section 4: Granular Test Case Generation (Single Test Case)

This method focuses on one test case at a time and offers the highest level of control.

Creating a Test Case

1. Go to Test Cases
2. Click Add Test Case
3. Enter a short test case description (name)
4. Add detailed AI Context
5. Click Generate actual test using AI

AI uses screenshots and context to build steps and reusable rules.

Iteration and Steering

• Add more context
• Insert partial steps
• Use AI to continue test generation

This iterative process is expected and encouraged.

Common Mistakes (Granular Generation)

• Providing minimal AI context
• Expecting AI to infer intent from the test name alone

Why AI Fails Here

• Expected results do not visually enable the next action
• Ambiguous instructions

Section 5: Importing Test Cases from Test Management Tools

testRigor supports importing documented test cases from tools such as Xray, TestRail, and Zephyr.

How Import Works

• Documented test cases are imported
• Each imported test case becomes AI context
• AI uses that context to generate executable steps and reusable rules

Imports can be processed at scale, but AI still generates automation one test case at a time. For this reason, each imported test case should describe one clear, linear scenario.

Use Linear Test Cases for Automation

A linear test case follows one main path from beginning to end and produces one expected outcome.

• Begin from a clearly defined starting point
• Follow one sequence of actions
• Describe one expected outcome
• Avoid branches that lead to different workflows or results

For example, a test case can verify that a user enters valid payment information, submits an order, and reaches the order confirmation page.

A separate test case should verify what happens when the payment information is invalid. Combining both outcomes into one test case creates multiple possible paths and makes it more difficult for AI to determine which flow it should automate.

When a Test Case Should Be Split

• Different user roles that follow different workflows
• Conditional branches that lead to different actions
• Multiple expected outcomes
• Several independent scenarios grouped into one test case
• Positive and negative scenarios within the same flow

Each resulting test case should be understandable and executable on its own.

A conditional does not always require a separate test case. A guard condition that handles a temporary or optional state and then returns to the same main flow can remain within the test.

For example, dismissing a popup only when it appears does not change the purpose or expected outcome of the scenario. However, a condition that sends the user through a different workflow or produces a different final result should normally be separated into another test case.

Manual Test Matrices vs. Automated Test Cases

Test matrices are often useful for manual testing because a tester can interpret rows, conditions, alternate paths, and expected results while executing the test.

That same structure can be counterproductive for AI-generated automation when one documented test case represents several different scenarios.

• Valid and invalid credentials
• Active and locked users
• Different permission levels
• Different expected landing pages or error messages

If these combinations lead to different workflows or outcomes, they should be imported as separate linear test cases.

If the steps and expected outcome remain the same and only the input data changes, the scenarios may be suitable for a dataset instead of separate test cases.

Important note: Use datasets for data variations within the same workflow. Create separate test cases when the variation changes the actions, navigation, or expected outcome.

Documentation Requirements

• Each test case should describe one linear scenario
• Steps must be explicit and unambiguous
• Actions and expected results should be clearly separated
• Each expected result should visually enable or confirm the next action
• Preconditions and required test data should be clearly documented
• Branches with different outcomes should be divided into separate test cases

AI can generate automation more successfully when the imported documentation gives it one clear path to follow. Preparing manual test cases for automation before importing them reduces ambiguity and makes the generated tests easier to review, correct, and maintain.

Section 6: Worked Example – Succinct Name vs Detailed AI Context

Test Case Name (Human-Friendly)

Verify cart updates and recalculation behavior

AI Context (Machine-Oriented)

User navigates to the Daily Deals page and adds a Deal of the Day item to the cart. User then browses to an accessories category, opens a product detail page, and adds a regular accessory to the cart. In the cart, user updates item quantities, removes one item, and moves one item to Save for Later. User uses the shipping estimator with a sample ZIP code to preview shipping cost and tax. Verify that the cart correctly recalculates subtotal, estimated shipping, and tax after each cart update, and proceed to the checkout review page without placing an order.

Why This Works

• Short names remain readable and maintainable
• Detailed AI context guides behavior without cluttering the test list
• Names and AI context can evolve independently

Key Takeaways

• Use AI to accelerate, not replace, test design
• Separate test case names from AI context
• Be explicit and unambiguous
• Use visuals whenever possible
• Expect iteration