Page History
...
| 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 |
Create, view, edit, clone tests
Specify
|
Attachments on Test Steps
| Review | |
| Notes |
|
| Mind Map View |
|
| Scorecard |
|
Preconditions for test cases
Reuse preconditions between test cases
Multiple preconditions for test cases
Organize
Organize tests by project, version, component and label
Organize tests in Test Sets
Plan
Test plans
Execute
Create, edit, clone and schedule test executions
Ad hoc style (execute unplanned tests)
Personalize and create Test Run and step statuses
Measure
Track with progress bars on Test Execution/Cycles and Test Plans
Track requirement coverage/status directly on issues, as an attribute
(Traceability, Test Plans and Test Executions metrics, Overall and Historic Requirement Coverage)
Number of built-in reusable gadgets
6
Explore and evolve
Advanced query language
(extensive list of JQL functions)
Characteristics
Consistency (Test changing non-retroactivity on past executions)
Using of Jira issues benefits
Test, Pre-Condition, Test Set, Test Execution, Test Plan
Configuration
Extensive configuration, including behavior
Per-project configuration
Support for project separation between requirements and tests
Agile integration
Seamless integration with Jira's native Agile boards
(see Test Plans and Test Executions associated with requirements)
Importing results
Cucumber, SpecFlow, Behave, Serenity BDD, Gwen, Xray JSON, TestNG, JUnit, NUnit, xUnit, Robot, RSpec, Selenium
Importing tests
Cucumber .feature(s), Excel/CSV, Zephyr for Jira, HP QC/ALM and tests from many different automated test frameworks
Exporting testing data to fully customized DOC/PDF/Excel with Xporter
Integration with other Jira related tools (e.g. Confluence)
Integration with other top-notch apps
UI-Supported languages
English, German, French, Spanish
Mobile app
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
Access Test Case Designer
| 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>