Date: Fri, 29 Mar 2024 09:17:40 +0000 (UTC) Message-ID: <1808963460.11232.1711703860961@docs.getxray.app> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_11231_1330084837.1711703860961" ------=_Part_11231_1330084837.1711703860961 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Scheduling executions of Tests can be made by creating Test Exec= utions containing the Tests that should be run.
In fact, a Test Execution contains Test Runs (i.e., instances of the Tes= ts in the context of that Test Execution). It contains a copy of the Test s= pecification along with the respective result.
Sometimes, you're testing in different target systems, browsers, devices= , and database providers.
If the Tests are exactly the same, but you want to track the results on = those different environments, then you should create Test Executions for ea= ch environment and assign the proper Test Environment value.
More info about Test Environments can be found in Working with Test Environments= .
The Test Execution provides two levels of assignments:
By default, the individual Test Runs are assigned to the same user as th= e Test Execution assignee. This is the simplest scenario.
Therefore, you can create different Test Executions for different person= s, each one will contain only the Tests aimed to be run by that person. In = this case, the Test Execution assignee would be the same as the assignee of= the individual runs.
Some teams have a QA manager/lead that is responsible for managing the l= ifecyle of the Test Execution, including
Test Executions may contain many Tests to be run. In this case, the Test= Execution assignee would be the QA manager while the individual Test Runs = would be assigned to one or more different persons.
For historical reasons, you should create a new Test Execution with the = Tests that you want to run in that version/revision of the system. That way= you'll be able to see the results you obtained in that specific iteration,= i.e., in that Test Execution that ran in a specific revision of the system= .
You can also update the same Test Execution but you'll loose the benefit= of tracking how your test results evolve through time.
Each project is different so you should create as many as needed in orde= r to ensure the quality of the product you're working on. The quantity and = the timing depends on the process and methodology you have implemented. A r= ule of thumb is you should start testing as soon as possible and avoid test= ing only at the end of your development cycle.
If you want to validate some components or subsets of the system, you ma= y create specific Test Executions for it. The how and when depends on your = approach.
No, you don't. They're optional. If you don't want to use them, just don= 't add that issue type to your project.
Sub-Test Executions provide an easy way to schedule an execution contain= ing all the Tests that validate a given requirement.
They are handled as sub-tasks of the parent requirement. This means that= you gain some out-of-the-box features such as the: