Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleModular Tests
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

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
colourGreen
titlev3.1


Expand
titleAutomated Steps Library
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

The Automated Steps Library will be BDD Step Library is a project-level steps library for BDD Tests/Preconditionsorganization feature, containing all the Gherkin steps referred by these issues.included by all Tests/Preconditions belonging to the project. Thus, it provides a facility to store and manage all steps, encouraging users to easily reuse steps across Tests/Preconditions with step autocompletion and discoverability when editing BDD scenarios and backgrounds with Xrayan 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.


bdd_step_lib.pngImage Added

Find out more about this feature here.

Expand
titleTime Tracking
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

Right now, a Test Run contains the start and finish date which are set automatically, although users can also change the start date manually. However, users can not stop and start the execution as needed and the total time spent on the Test Run (finish - start) might not reflect the time spent by the user executing the Test.

We plan to provide a feature to allow users to pause and continue with the execution directly on the Test Run screen. 

...

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.


time_tracking.pngImage Added


Learn more here.


In the works


Expand
titleTesting board
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

The goal behind the testing board is to provide a centralized hub for accessing Xray entities and activities in order to improve navigation and discoverability. For now, this board features the Test repository, the Test Plan board, and project reports. 

The testing board will be improved to include other Xray entities such as Preconditions, Test Sets, and Test Executions. The Test Run and execution screen will have the testing board in context so that users can navigate to any other test activity.


Wish list for future versions


Expand
titleTest natures
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

This feature will cover a common scenario where manual Test cases evolve to automated Tests. In this case, the only option is to create separate Test issues to cover all the natures for the Test.

With Test natures, multiple Test definitions can coexist within the same Test case. Users will also be able to set the current definition so that Test Runs are always created using the "current" definition.

Expand
titleTest Environment variables
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

This feature will allow test engineers to create or generate environments with variables such as Browser, Operating System, Database, etc. These environments (or configurations) can be managed and assigned to Test Plans and Test Plan folders. Test Executions can then be created automatically for each environment/configuration.

Xray will provide a report to track the progress of Test Runs by environment in the context of a specific Test Plan.

Expand
titleUpdated Xray connector app for Bamboo
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

The Xray Connector app for Bamboo will be updated in order to support Xray cloud APIs and connectivity.

Expand
titleTest natures
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

This feature will cover a common scenario where manual Test cases evolve to automated Tests. In this case, the only option is to create separate Test issues to cover all the natures for the Test.

With Test natures, multiple Test definitions can coexist within the same Test case. Users will also be able to set the current definition so that Test Runs are always created using the "current" definition.

Expand
titleDynamic Test Plans
Panel
borderColor#EAECEE
borderWidth1px
borderStylesolid

Currently, the Test Plan is composed of a static list of Test cases. This means you must explicitly add the Tests to the Test Plan. If the Tests are all known and well defined when you start your Test Plan, this is ok. However, if you are working in an agile context where a Test Plan is created for a specific sprint, Tests will only be specified during the sprint and later added to the Test Plan. This process is not ideal because users might forget to add the Tests to the Test Plan.

Dynamic Test Plans can be defined with a JQL query which will be the source for Test cases. Considering the use case described above, we can define a JQL query that will get all Tests covering requirements of a specific sprint.

...