Generating the Test Case with AI Test Case Assistant 1.0
Follow the steps below to generate a test case:
Step 1: Analyze the Item
1. In the Document View or Document Edit View, select an item and click Analyze on the AI Test Case Assistant start page. The AI Test Case Assistant analyzes the description of the item and enables the Coverage step. This step displays the Test Breakdown page.
The
Test Breakdown page displays the generated test conditions. You can manually add additional test conditions in this step using the

icon. You can edit or delete the manually added test conditions using the

and

icons.
| • The AI Test Case Assistant generates test case conditions using an LLM. If the administrator has provided additional context or guidelines using the Set AI Context option, that context is appended to the input passed to the LLM. The test case conditions are then generated based on those guidelines along with the LLM input. • Before using the assistant, we recommend that you review and improve your requirement—or use the Requirement Analysis tool. Providing clear, high-quality input helps the assistant generate accurate and useful test cases. • Test conditions are not saved. They are automatically regenerated when you rerun the analysis or return to the Test Breakdown page after navigating away. |
2. Click

to display the existing test cases covered under the
AI Test Case Assistant generated test conditions and manually added test conditions.
| After manually adding a test condition, click the  again to refresh the coverage results. |
3. To filter the test conditions based on the coverage:
a. Click the

on the
Test Breakdown page.
b. Select Show all conditions to display all available test conditions for the test case.
c. Select Show conditions without coverage to filter test conditions that do not have any test cases covered under them.
4. Select a test condition against which you want to generate a new test case and click

. The
Type step is enabled.
Step 2: Select the Test Type
1. The Type step displays the Test Types page. The following system-defined test types are listed by default:
◦ Boundary Value Analysis— A testing technique used to identify errors at the boundaries of input domains rather than within the range. It is based on the observation that defects often occur at the extreme ends of input values.
◦ Compatibility Testing— A type of non-functional testing to validate that an application or system works as expected across different devices, operating systems, browsers or network environments.
◦ Equivalence Partitioning— A type of testing technique used to reduce the number of test cases while maintaining effective coverage. It works by dividing input data into partitions (or classes) where all values in a partition are expected to behave similarly.
◦ Error Guessing— A testing technique that relies on the tester’s experience and intuition to identify areas in the application where defects are most likely to occur. It is considered an experience-based testing method rather than a systematic one.
◦ Performance Testing— A type of non-functional testing that evaluates how a system behaves under various conditions, focusing on its speed, scalability, stability, and responsiveness. The goal is to ensure the application meets performance criteria and provides a smooth user experience.
◦ State Transition Testing— A type of testing technique used to validate how a system behaves when transitioning between different states based on events or inputs. It is particularly useful for applications where the output depends on both the current state and previous state.
◦ Static Analysis— A software quality assurance technique that examines the source code, compiled code, design or documentation without executing the program. The goal is to detect potential errors, vulnerabilities, or compliance issues early in the development lifecycle.
◦ Usability Testing— A non-functional testing technique that evaluates how easy and user-friendly an application or system is for its intended users. The primary goal is to ensure that the product provides smooth, intuitive, and efficient user experience.
◦ Use Case Testing— A testing technique that validates whether a system behaves as expected when executing real-world scenarios described in its use cases. It focuses on end-to-end functionality from the user’s perspective.
◦ Generic Testing— This test type creates a generic test case when none of the predefined test types cover the intended scenario.
2. Select a test type and click

. The
Details step is enabled.
Step 3: Review and Edit the Test Case Details
1. The Details step opens the Test Case Details page, where fields such as Name, Description, and Pre-action are automatically populated with AI-generated content. You can manually edit any of these fields if required. Note that these fields support only plain-text.
2. Click

, the
Outline step is enabled.
Step 4: Review and Edit the Test Case Outline
1. The
Outline step displays the
Test Case Outline page. The Test Case Outline shows the framework of the test case, that is, the test steps. Based on your testing requirements, you can add new test steps or delete existing test steps using the

and

icons. You can also reorder the steps in the outline using the drag handles

.
2. Click

, the
Steps step is enabled.
Step 5: Review and Edit the Test Steps
1. The Steps step displays the Test Steps page. This page list the steps that will be included in the test case.
2. Click Expand All to view the Action and Expected Results fields for each step. Edit the Action and the Expected Results, if required.
| The Action and Expected Results fields support only plain-text. |
Step 6: Save the Newly Created Test Case
1. Once you have reviewed the test steps in Test Steps page, click

in the
AI Test Case Assistant footer to save the test case. The
Save Test Case dialog opens.
◦ For Codebeamer version 3.1 and later:
The Save Test Case dialog displays the following fields: Stream, Project, and Tracker.
▪ The Stream and Project drop-down lists show the current stream and project as the default selections.
▪ You can change the default selection in the Project drop-down if needed.
▪ The default selection in the Stream drop-down cannot be changed.
◦ For Codebeamer versions 2.2.1.2 and 3.0.0.3:
The Save Test Case dialog displays the following fields: Project, Working Set, and Tracker.
▪ The Project and Working Set fields show the current project and working-set as the default selections.
▪ You can change the default selection in the Project drop-down only if you are currently in the default working-set.
▪ The default selection for the Working Set drop-down cannot be changed.
2. Select the required test case tracker in the Tracker drop-down.
| The Tracker drop-down shows only those trackers that have the custom fields Last Influenced by AI and Influenced by AI configured. For more information, see Configure Custom Fields for Trackers. |
3. Click Save. The new test case is saved in the selected Stream/Project/Tracker or Project/Working-Set/Tracker based on the Codebeamer version that you are currently on. When save is complete, Codebeamer displays a success message with a link to the new test case. The new test case is marked with Influenced by AI field set to true, along with Last Influenced by AI field updated with the latest date and timestamp.
Considerations When Generating and Saving the New Test Case
• When you save a test case created by the AI Test Case Assistant, any mandatory fields previously set are not automatically enforced. We recommend that you review the saved test case and fill in any required fields to make sure the test meets your project or tracker requirements.
• You cannot save test cases across different Working-Sets or Streams. The target test case tracker must be in the same Working-Set or Stream as the original tracker.
Special Use Cases
Use Case | Outcome |
|---|
After generating the test steps and before saving the test case, the user updates the target tracker’s configuration to remove the custom AI fields. | Custom AI fields may be removed if the tracker configuration for the target test case is modified in another tab or session. In a real-time, this issue could occur in the following scenarios: • Scenario 1: If the same user inadvertently modifies the tracker configuration in another browser tab while working on a different task. • Scenario 2: If two users with the necessary permissions are working simultaneously—one saving the new test case while the other modifies the tracker configuration. |
| Saving the test case fails. |
During test case generation, the user changes data on a particular page and then navigates to a previous page and updates the data on that page. | Your manually made changes in the original page are lost as AI regenerates the data on this page. |