Page History
...
- 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.
...
| Section | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Features
...
| Supported? | |
|---|---|
| Create, view, edit, copy Test Models |  |
| Test Model revisions |
|
| Import Test Models from Excel |
|
| Import Test Models from mind maps (OPML) |
|
| Share Test Models |
|
| Export Test Models | |
| Parameters | |
| Create, view, edit Parameters |
|
| Order Parameters |
|
| Add Value Expansions |
|
| Bulk update |
|
| Rules | |
| Constraints definition |
|
| Invalid constraints |
|
| Bound constraints |
|
| Forced Interactions definition |
|
| Import Forced Interactions |
|
| Scenarios | |
| Standard and optimized scenarios generation |
|
| Multi way interactions |
|
| Mixed-strength interactions |
|
| Scenario Freeze option |
|
| Export Scenarios |
|
| Scripts | |
| Manual Tests |
|
| Native support for BDD (Gherkin/Cucumber) |
|
| Analysis | |
| Coverage Matrix |
|
| Coverage Graph |
|
| Review | |
| Notes |
|
| Mind Map View |
|
| Scorecard |
|
Access Test Case Designer
< Include requirements ( Xray Enterprise License> and screenshots on how to access Test Case Designer)
Terms & Concepts
< Explain all the main concepts and then link to pages where the user can learn how to use them>
Test Model
Parameters
Rules
Scenarios
Scripts
Quick Getting Started
| Note |
|---|
Xray Test Case Designer is a feature included in Xray Enterprise offer, to access this feature you need to make sure that:
|
When a valid Xray Enterprise license is detected, a new Xray Enterprise configuration option will be made available to setup your Test Case Designer instance
Initial Setup
| UI Steps | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Terms & Concepts
Test Model
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"). To find bugs related with the input parameters and increase the related coverage, an optimized set test cases (manual or automated) can be derived from it. More info on Test Models here.
Parameters
The parameters are used to define the variables, and the related possible values, that are applicable to the Test Model. Usually these refer to the input variables.
Parameters, together with the restrictions specified using Rules, will be used to derive the combination of parameter/values.
| Info |
|---|
| Test parameterization is a powerful practice that allows the same test to be executed multiple times with different parameters. Parameters are similar to input values (variables) that can change with each execution. |
Rules
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.
In the other hand, Rules can also be used to enforce scenarios where parameter values can only be tested together.
More info on Rules here.
Scenarios
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 parameter/values are created. Test Case Designer uses coverage optimization algorithms (pairwise, n-wise) to achieve a high level of coverage with in few tests. This can be adjusted to achieve a greater coverage if needed. More info on Scenarios here.
Scripts
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 the 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 they can be replaced later on by proper values. More info on Scripts here.< Explain briefly how to use Test Designer - First you create parameters, then rules, etc etc>