Page History
Note |
---|
Xray's roadmap is continuously reviewed and redefined. We update often, depending on the feedback we receive from our clients and internal stakeholders. Our release plan is available in our Jira issue tracker. Feel free to view and to vote on the issues that you would like to see implemented (account registration required). Here you can find a list of features that define our main goals for future releases. This doesn't mean that other, potentially smaller features, won't be implemented as well. |
Shipped
Status | ||||
---|---|---|---|---|
|
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Status | ||||
---|---|---|---|---|
|
At Xray, we are always listening to our customers and stakeholders to improve our product and deliver the best value. Our roadmap reflects our vision and priorities for the upcoming releases. |
UI Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
Expand | ||||||
| ||||||
Panel | You can now define additional custom fields for Test Runs. These fields can be useful to add extra information to Test Runs usually only available during or after executing Tests. Test Run custom fields can be configured by project and by Test Type. Therefore, these settings will not affect other projects within your Jira instance. For example, it is possible to have custom fields just for Manual Tests within a project. Reporting The Test Runs List report and gadget can already display Test Run Custom Field values for each Test Run. Within a Test Execution issue, it is also possible to display Test Run Custom Field columns and to filter Test Runs by Test Run Custom Field values. Learn more about Test Run Custom Fields here.
|
...
title | Parameterized Tests and data driven testing |
---|
...
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.
Parameterized tests in Xray are defined just like any other test with the addition of some parameter names within the specification using the following notation: ${PARAMETER_NAME}. This notation is used to reference parameters within the test steps.
Precondition issues can also be parameterized by including parameter names in the precondition specification.
The parameters, along with their values, are defined within a dataset. A dataset is a collection of data represented with a tabular view where every column of the table represents a particular variable (or parameter), and each row corresponds to a given record (or iteration) of the dataset. The number of rows in the dataset determines the number of iterations to execute.
A dataset can be defined in the following entities/scopes:
- Test (default dataset)
- Test Plan - Test
- Test Execution - Test (Test Run)
The closest dataset to the test run will be the one used to generate the iterations, effectively overriding any dataset defined in higher levels.
All iterations for a given test are executed within the context of the same test run. Each iteration can be expanded, and the steps executed individually. The step parameters will be replaced by the corresponding iteration values. The steps affect the iteration status that, in turn, affects the overall test run status.
Learn more about parameterized tests here.
Status | ||||
---|---|---|---|---|
|
...
title | Modular Tests |
---|
...
borderColor | #EAECEE |
---|---|
borderWidth | 1px |
borderStyle | solid |
Modular test design is a way of promoting test case reusability and composition across a large test repository. To design modular tests, you can create a test where some of the steps call or include other test cases. This prevents testers from having to write the same steps over and over again in different high-level tests. Using a modular design approach, any test can become a building block of more extensive test scenarios. Still, they can also be executed individually if needed.
A called test can, in turn, also call other tests. You can compose a test scenario with up to five levels of depth.
Modular tests can also be parameterized. When calling a test, you can provide new parameter values according to the parent test data.
Upon executing, Xray will unfold all called test steps in the test run. This becomes transparent to testers as they only have to follow and execute the steps on the execution, even though test steps might come from different tests issues.
A common use case for modular tests is end-to-end testing. End-to-end tests often need to pass through the same area or component of the application before asserting the final result. With modular test design, you can reuse the tests for these common areas or components.
Learn more about modular tests here.
Status | ||||
---|---|---|---|---|
|
...
title | Automated Steps Library |
---|
...
borderColor | #EAECEE |
---|---|
borderWidth | 1px |
borderStyle | solid |
The BDD Step Library is a project-level steps library organization feature, containing all the Gherkin steps included by all Tests/Preconditions belonging to the project. Thus, it provides an overview of all the Gherkin steps used in the context of each project, allowing users to easily manage and refactor the steps.
You can also configure heuristics in order to recognize variables within the steps. This way, Xray is able to identify a single step from multiple steps within Tests/Preconditions where the only thing that varies is the parameter values.
It is also possible to create static steps. Static steps can be created manually within the BDD library and are not deleted even if there are no Tests/Preconditions using these steps.
Besides project libraries, it is also possible to configure global BDD libraries that can be accessed from multiple projects. Hence, if you have multiple Jira projects using the same Gherkin steps you can also use the same BDD library in Xray.
When creating BDD tests or preconditions, you can now use auto-complete to reuse a step that you already have in the library.
Find out more about this feature here.
Test cases evolve when requirements change, or improvements are made to the application under test. Although Xray logs test specification changes in the Jira history, it is not easy to revert to a specific test case version. With Test case versioning, you can now create multiple versions of the same test. |
UI Expand | ||
---|---|---|
| ||
By defining a saved filter as the source of Tests for the Test Plan, all Tests on the filter will be added automatically into the Test Plan by Xray. For example, you can define a Test Plan with a filter containing the Tests associated with Stories from a Sprint. Your Test Plan will collect all relevant Tests for that Sprint automatically. If a Test Plan is configured with a saved filter, users can't add or remove Tests explicitly from the Test Plan. |
UI Expand | ||
---|---|---|
| ||
By defining a saved filter as the source of Tests for the Test Plan, all Tests on the filter will be added automatically into the Test Plan by Xray. For example, you can define a Test Plan with a filter containing the Tests associated with Stories from a Sprint. Your Test Plan will collect all relevant Tests for that Sprint automatically. If a Test Plan is configured with a saved filter, users can't add or remove Tests explicitly from the Test Plan. |
UI Expand | ||
---|---|---|
| ||
Our goal is to improve the migration process by allowing extra options that can ensure a successful outcome. We will provide a list of issues that may arise during the process and how to resolve them. We will also optimize the process to achieve the migration in the least amount of time possible, without compromising the quality or integrity of the data. |
UI Expand | ||
---|---|---|
| ||
Improve the way defects are created by cloning parent issue data. e.g. if test has component selected, the bug created will inherit that value. |
UI Expand | ||
---|---|---|
| ||
This gadget enables you to see, at a glance, the evolution/trend of the status of a group of Tests, taking into account the results of those Tests in certain Test Executions. |
UI Expand | ||
---|---|---|
| ||
The main objectives of the improvements are to increase the test coverage, reduce the execution time, and enhance the readability and maintainability of the test library |
...
title | Time Tracking |
---|
Xray now provides a time tracking module within the execution page. This module allows users to record the time spent executing a test by controlling a stopwatch.
The stopwatch is also synchronized with the Test Run status. When you start executing a step, the stopwatch starts counting. When you set a final status on the Test Run, the stopwatch stops.
You can also log work directly from the execution screen, just like you do within Jira issues. Any logged time will be added automatically to the Test Execution issue log work.
Learn more here.
In the works
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Wish list for future versions
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
Panel | | |||||
|