Date: Fri, 29 Mar 2024 11:23:54 +0000 (UTC) Message-ID: <297231515.11588.1711711434528@docs.getxray.app> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_11587_1644571553.1711711434527" ------=_Part_11587_1644571553.1711711434527 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Having the Test Process in mind will help you implement quality assura= nce in your projects. The different testing phases (i.e., specifying, organ= izing, planning, executing, analyzing/reporting) are mostly implemented as = issue types. More information about each phase can be obtained in each spec= ific section within this documentation.
Learn more
Please take some time to learn the terminology used in Xray and the rela= tionships between its entities in Terms and Concepts.
If your teams are adoption Agile, namelly Scrum or Kanban frameworks, pl= ease have a look at the general guidelines for Agile software development, namelly = Using Xray in an A= gile context for specific and more in-depth recommendations concerning = Xray usage in such scenarios.
The following sections give an overview on Xray usage in case you're man= aging versioned projects or not.
Not every team uses versions (also know as Releases in Jira), but still = they need ways to manage and track their testing.
In this use case, your project has one or more versions that you evolve = as needed.
You may start with some requirements for v1.0 and later on create a v1.1= or a v2.0 release, and so on.
How do you then implement testing in this scenario?
Suppose that you are working in version "XPTO" and you want to test it t= o make sure that the features you deliver are correct.
Your workflow would be more or less:
Organize your Tests eit=
her in lists (i.e., Test Set issues) or in folders, so yo=
u can easily pick them afterwards whenever you need to create executions or=
plans. Test Sets can also be used as a way to indirectly validate requirem=
ents, since you can link them to requirements using the "tests" issue link.=
Create at least one Test Plan w=
ith the Tests you want to validate in version XPTO. Don't forget t=
o assign the Test Plan with version XPTO using the FixVersion=
field.
Learn more
Check out our Tip= s for planning tests, which explore the different testing possibilities= , including in Waterfall and Agile methodologies.
You may be implementing Continuous Integration and Continous Delivery wi= th the help of automated testing. How can you adapt your process to this sc= enario?
If you're using an Agile methodology, such as Scrum, then you have Sprin= ts that you can use as basis to define some scope.
Note that Scrum does not require you to make just one delivery at the en= d of each Sprint; you can deliver many during the lifespan of a Sprint.
Suppose that you are working in version "XPTO", sprint "X", and you want= to test it to make sure that the features you deliver are correct.
Your workflow would be more or less:
Create one or more Tests for va=
lidating each requirement. In this case, your automated test=
s will be specified before the actual implementation of the requirement is =
done, if you're following TDD, or after the requirement is implemented, in =
the worst case scenario. Cucumber automated tests can be specified in Jira =
(and implemented in code), while other automated tests will be written in c=
ode and either linked to the requirement directly in the code or manually a=
fter importing their respective results.
Create at least one Test Plan w= ith the Tests you want to validate in version XPTO. Don't forget t= o assign the Test Plan with version XPTO and sprint X. Having a specific Te= st Plan for tracking the regression testing may prove to be useful.
<= br>
This may be common in Continuous Delivery scenarios or in the case where= you simply don't want to manage versions at all. How do you implement test= ing in this scenario?
If you're using an Agile methodology, such as Scrum, then you have Sprin= ts that you can use as basis to define some scope.
Suppose that you are working in sprint "X" and you want to test it to ma= ke sure that the features you deliver are correct.
Your workflow would be more or less:
Organize your Tests either in l=
ists (i.e., Test Set issues) or in folders, so you can easily pick=
them afterwards whenever you need to create executions or plans. Test Sets=
can also be used as a way to indirectly validate requirements, since you c=
an link them to requirements using the "tests" issue link.
Create at least one Test Plan w= ith the Tests you want to validate in sprint X. Don't forget to as= sign the Test Plan with sprint X.
You may be implementing Continuous Integration and Continous Delivery wi= th the help of automated testing. How can you adapt your process to this sc= enario?
If you're using an Agile methodology, such as Scrum, then you have Sprin= ts that you can use as basis to define some scope.
Note that Scrum does not require you to make just one delivery at the en= d of each Sprint; you can deliver many during the lifespan of a Sprint.
Suppose that you are working in sprint "X" and you want to testing it to= make sure that the features you deliver are correct.
Your workflow would be more or less:
Create one or more Tests for va=
lidating each requirement. In this case, your automated test=
s will be specified before the actual implementation of the requirement is =
done, if you're following TDD, or after the requirement is implemented, in =
the worst case scenario. Cucumber automated tests can be specified in Jira =
(and implemented in code), while other automated tests will be written in c=
ode and either linked to the requirement directly in the code or manually a=
fter importing their respective results.
Create at leas= t one Test Plan with the Tests you want to validate in sprint X. D= on't forget to assign the Test Plan with sprint X. Having a specific Test P= lan for tracking the regression testing may prove to be useful.