Xray Test Case Designer is a revolutionary test design optimization tool that will increase the effectiveness of your testing.
The tool can be used by teams in the early stages of the testing process (and by teams creating scenario-based requirements). Benefitting from Intelligent Augmentation algorithms, test sets created by the Test Case Designer have been repeatedly proven to find more defects (and find them more efficiently) than hand-selected test sets.
To do so, the tool carefully constructs combinations of test conditions to achieve as much coverage as possible in as few tests as possible using applied statistics-based optimization methods that have been refined over more than 40 years.
This is the core feature of Xray Test Case Designer, and to achieve that, it focuses on these areas:
- Systematically avoiding wasteful repetition.
- Systematically covering not only all user-specified requirements but also 100% of all of the application’s critical interactions.
- doing so in the lowest mathematically possible number of tests.
With Xray Test Case Designer, you’ll test much faster. You’ll also achieve objectively much better tests. Let’s begin by discussing three key ways Xray Test Case Designer will save you and your colleagues time, as well as how the scenarios you’ll generate using the tool are far more thorough than the ones selected by hand.
Generate test models in seconds at the push of a button.
Generating the test models in the Test Case Designer is a fundamentally different process than selecting and documenting individual tests by hand, one by one. To generate optimized scenarios using the Test Case Designer, you must first identify inputs and variation ideas and enter them into the tool.
Once identified, you’ll be able to generate entire sets of extremely thorough and highly efficient scenarios in seconds and adjust them as necessary.
Clearly communicate testing coverage for faster approvals.
Each time you generate a set of scenarios, the Test Case Designer automatically creates insightful interaction coverage reports that clarify precisely what (and what is not) covered after any scenario you choose. These visualizations facilitate clear and efficient communication between stakeholders. With Xray Test Case Designer’s coverage reports in hand, you will immediately have clear, actionable, and fact-based answers to the questions posed above and the related questions of “How many tests are enough?”
Quickly transform optimized scenarios into automated tests
If a large percentage of your automated tests today are individually written using hard-coded variables, the SDETs, Developers, and/or automation engineers responsible for scripting and maintaining those would love our tool.
Xray Test Case Designer enables accelerated, optimized in-sprint automation with which you can:
- Rapidly create clear, consistent steps that leverage Behavior Driven Development principles (the largest benefit is the one-to-many relationship between Xray Test Case Designer scripts and the data scenarios.)
- Export one Scenario block into multiple skeletal scripts based on your chosen language.
- Maintain and reuse the script components much faster thanks to the model-based approach.
Eliminate wasteful redundancy
Stop hand-selecting redundant tests.
The most common type of wasteful repetition is that specific system paths, and combinations of test inputs get tested repeatedly in test after test.Based on our experience, thousands of hand-selected test sets, even when those sets achieve “requirements coverage,” consistently fail to test critical system interactions thoroughly.
Eliminate Gaps in Coverage
Reach 100% coverage in fewer tests.
Xray Test Case Designer uses sophisticated test generation algorithms powered by Intelligent Augmentation to eliminate these coverage gaps systematically. Whether a system under test has 50 critical interactions or 50,000 critical interactions, the Test Case Designer will keep track of 100% of them and ensure your tests cover all of them (and do so in the fewest possible scenarios).
Maximize variation and thoroughness.
Simple interactions within a system trigger the majority of software defects.
Every test you generate with the Test Case Designer is optimized to achieve maximum coverage, allowing teams to achieve greater coverage in fewer overall tests.
Xray Test Case Designer will guarantee that 100% of those system interactions are covered in as few tests as possible.
|Create, view, edit, and copy Test Models.|
|Test Model revisions|
|Import Test Models from Excel|
|Import Test Models from mind maps (OPML)|
|Share Test Models|
|Export Test Models|
|Create, view, and edit Parameters|
|Add Value Expansions|
|Forced Interactions definition|
|Import Forced Interactions|
|Standard and optimized scenarios generation|
|Scenario Freeze option|
|Native support for BDD (Gherkin/Cucumber)|
|Mind Map View|
Access Test Case Designer
Xray Test Case Designer is a feature included in Xray Enterprise offer. To access this feature, you need to make sure that you have the following:
- An active Xray license
- An Xray Enterprise active license
- Minimum Xray version 6.3.0
When a valid Xray Enterprise license is detected, a new Xray Enterprise configuration option will be made available to set up your Test Case Designer instance.
Access the new "Xray Enterprise" global option.
Provide the specific URL that Xray provided you (If you don't have this URL please get in touch with support)
The Test Case Designer menu option is now available on your Xray-enabled projects.
Terms & Concepts
A Test Model is an abstraction of a focused use case that we aim to test. This model is made around a specific scope (e.g., "book a flight") that can be exercised in different ways, depending on a combination of input parameters (e.g., "origin, destination, number of seats, date"). An optimized set of test cases (manual or automated) can be derived to find bugs related to the input parameters and increase the related coverage. More info on Test Models is here.
The parameters are used to define the variables, and the related possible values, that apply to the Test Model. Usually, these refer to the input variables.
Parameters and the restrictions specified using Rules will be used to derive the combination of parameters/values.
More info on Parameters is here.
While Parameters are used to enumerate, in general, the variables in our Test Model and the values they can have, Rules allow us to apply some restrictions as we may not be interested in having all the combinations of these variables.
Rules can be used to define what parameter values can never be tested together, as they either don't make sense in reality (e.g., Windows + Safari) or because they may not be representative/relevant.
On the other hand, Rules can also be used to enforce scenarios where parameter values can only be tested together.
Scenarios are the generated combination of input parameter values, where each row represents a combination of parameters (and their values) to be used in a test.
We can think of Scenarios as an optimized dataset that will be used to iterate our Test Model multiple times and thus test it under slightly different circumstances.
Not all combinations of parameters/values are created. Test Case Designer uses coverage optimization algorithms (pairwise, n-wise) to achieve a high level of coverage within few tests. This can be adjusted to achieve greater coverage if needed. More info on Scenarios is here.
While Scenarios focus on data that will be used for our tests, Scripts provide the actual context so that testers know how/where to apply it.
Scripts have detailed steps with actions and expectations for our test scenarios.
Scripts can be either manual test scripts or automated test scripts.
For manual test scripts, detailed steps and expected results can be specified, where parameters may be mentioned. These will be replaced by the respective values whenever generating the tests later on.
For automated test scripts, Gherkin (e.g., Cucumber) Scenario or Scenario Outline can be specified or even Robot Framework test cases. Similarly to manual test scripts, parameters can be mentioned in the specification so that they can be replaced later on by proper values. More info on Scripts is here.