Community Tip - Your Friends List is a way to easily have access to the community members that you interact with the most! X
Hi all,
Here the scenario:
All tests are performed manually using the Test Result Editor, there is no automation framework involved.
All our Test sessions are related to a "Device Description" Item that holds the detailed Hardware and Software Setup Information of the tested device used in the Session (where a "device" is one specific combination of several electronic units each with individual Hard and Software).
Our test case items contain an optional field "required environment" that basically holds information on what electronic unit(s) must be part of the tested device, so that the testcase is applicable.
The test cases are organized in TestSuite Documents e.g. based on function groups.
To increase productivity for the Test engineers I would like to have a "default" test result (verdict = NA -not applicable) created automatically for every test case in a session where the "required environment" of the testcase is defined and the values do not match the values defined in the session's "Device Description".
To keep a long story short: "If it cannot be tested, mark it as NA"
My Idea was to write a trigger script that is fired when the session changed it's state to "in Testing"
I how to iterate the test cases using "walkHierarchy" from the ScriptIssueBean,
but what would be the best way to create the test results?
Thanx for all replys
Hello Matthias,
This is not possible. Specifically, the only way to get an editable context of a Test Result (TestResultDeltaBean) is through a Test Result Changed trigger.
Please contact Integrity Support and have your organization added to RFC 211872.
Sorry I don't have anything more fruitful.
Regards,
Kael
Hi Michael,
I knew that there is nothing usable in the JAVA trigger API.
Currently I have to decide whether to
Any ideas?
Hi Matthias,
Have you considered using the Java API from within the trigger script? Generally I try to avoid using the API from a trigger whenever possible as there is a potential for deadlocks and unwanted consequences (e.g. if the API command causes further triggers to run), but it is typically safe for read operations and because test results are not regular Integrity items I believe will be safe in this case. Do you have any triggers that fire based on test results? If you have such a trigger you will need to think through all the scenarios carefully.
For this particular case I would give the Java API a shot as I think it is the simplest and cleanest approach. From the ScriptEnvironmentBean you can get a ScriptAPISessionBean from which you can "executeCmd" to run a command analogous to the CLI. You should be able to use the ScriptIssueDeltaBean for the current session ID and to find your desired test cases, then craft a "tm createresult" API command to set the N/A verdicts for you.
Best regards,
Marcus
Hello Matthias,
Was Marcus' message at all helpful for you?
Regards,
Kael