-
Improvement
-
Resolution: Done
-
Major
Request for change for the plugin: Micro Focus Application Automation Tools
Currently the plugin allows to use Junit standard XML files in order to upload test results to ALM. The current XML structure does NOT allow to indicate the test version executed.
We need to be able to indicate the test version executen within the XML file uploaded in ALM.
Let me explain it with an example:
| <?xml version='1.0' encoding='UTF-8'?> <result> <suites> <suite> <file>Changes file</file> <name>Changes Test Set</name> <duration>2.293</duration> <cases> <case> <duration>8.293</duration> <className>ChangesManagement</className> <testName>List changes</testName> <testVersion>4.0</testVersion> <skipped>false</skipped> <failedSince>0</failedSince> </case> </cases> </suite> </suites> <duration>0.576</duration> </result> |
The tag testVersion is a non-supported tag, and in this case, the plugin will fail.
In this case, we want to be able to inform the Test Version Number of the instance in the Test Set:
We think that this is a very common situation where typically test cases have different versions and maybe you are execution a version that it’s not the current one, so the plugin should be able to inform the version of the test executed.
See attached file.
[JENKINS-60174] To be able to inform test version executed
Sergio Cuenca
added a comment - We use the field “Version Number” of the Test Case which is a OOB field (TS_VC_VERSION_NUMBER). It indicates the version of the test case.
Our scenario is:
1. Let’s imagine we have a test case, called Test X. The test X has 3 versions (it has been modified through the time to modify steps, add more steps, or remove some steps, I don’t care).
2. Then, we have the version 2.0 automated in an external automation tool.
3. We execute the version 2.0 of the test in the external automation tool and we want to load these results in ALM.
4. Currently, when we load the results, the “Version Number” inside the Test Instance, is empty, So we don’t know to which version of the test case this execution corresponds to.
5. So, what we need is to be able to spcify the Version Number inside the XML and load this information. Something like that:
<?xml version='1.0' encoding='UTF-8'?>
<result>
<suites>
<suite>
<file>Changes file</file>
<name>Changes Test Set</name>
<duration>2.293</duration>
<cases>
<case>
<duration>8.293</duration>
<className>ChangesManagement</className>
<testName>List changes</testName>
<testVersion>2.0</testVersion>
<skipped>false</skipped>
<failedSince>0</failedSince>
</case>
</cases>
</suite>
</suites>
<duration>0.576</duration>
</result>
Sergio Cuenca
added a comment - We use the field “Version Number” of the Test Case which is a OOB field (TS_VC_VERSION_NUMBER). It indicates the version of the test case.
Our scenario is:
1. Let’s imagine we have a test case, called Test X. The test X has 3 versions (it has been modified through the time to modify steps, add more steps, or remove some steps, I don’t care).
2. Then, we have the version 2.0 automated in an external automation tool.
3. We execute the version 2.0 of the test in the external automation tool and we want to load these results in ALM.
4. Currently, when we load the results, the “Version Number” inside the Test Instance, is empty, So we don’t know to which version of the test case this execution corresponds to.
5. So, what we need is to be able to spcify the Version Number inside the XML and load this information. Something like that:
XML result
<?xml version='1.0' encoding='UTF-8'?>
<result>
<suites>
<suite>
<file>Changes file</file>
<name>Changes Test Set</name>
<duration>2.293</duration>
<cases>
<case>
<duration>8.293</duration>
<className>ChangesManagement</className>
<testName>List changes</testName>
<testVersion>2.0</testVersion>
<skipped>false</skipped>
<failedSince>0</failedSince>
</case>
</cases>
</suite>
</suites>
<duration>0.576</duration>
</result>
Hi scuenca,
A normal test instance doesn't have “Test Version Number”, “Test Version Date”, “Test Version Time”. Are they user defined fields?
Sergio Cuenca
added a comment - Hi Roy,
Yes, you are right. Sorry i mean the test case version.
In the instance detail screen you can see the test case versión number:
Which Will be the same that you see in the test case detail screen:
In addition, the run also have a Test Versión Number (as you can see it is a OOB field):
What we want to do is to inform the test case versión number inside the RUN that we load from Jenkins.
In a manual execution, the versión displayed in the test instance detail screen corresponds to the test case versión and also the run versión corresponds to the test case versión executed. In regulatory environments, the versioning and the traceability is very important and it is a must for our use case. That's the reason why i am requesting that.
Thanks!
Sergio Cuenca
added a comment - Hi Roy,
Yes, you are right. Sorry i mean the test case version.
In the instance detail screen you can see the test case versión number:
Which Will be the same that you see in the test case detail screen:
In addition, the run also have a Test Versión Number (as you can see it is a OOB field):
What we want to do is to inform the test case versión number inside the RUN that we load from Jenkins.
In a manual execution, the versión displayed in the test instance detail screen corresponds to the test case versión and also the run versión corresponds to the test case versión executed. In regulatory environments, the versioning and the traceability is very important and it is a must for our use case. That's the reason why i am requesting that.
Thanks! 
Hi scuenca,
There's no test version concept in ALM. As the test result will be parsed to ALM test set, test and run. What would you like the test version belong to? I mean should it be a field of ALM test set or ALM test or ALM run?
Per my understanding, different versions for Junit test may be different tests for ALM test. Correct me if I'm wrong.
BR,
Roy