It's all about the answers!

Ask a question

Inconsistency in Test Suite Execution results


Rich VanDenburg (611) | asked May 06 '14, 3:27 p.m.
I have a Test Plan which consists of Test Suite and Test Case link to a Test Plan.   I have created the Test Suite Execution and Test Case Execution records respectively.  When I look at the Test Case Execution records, it does not appear if there is way to differentiate if the execution record was created from the Test Suite or Test Case.   Is there one that I am not seeing?   Also I get different status results in the Test Suite Execution console regarding tests I have executed based upon where I trigger the execution from ... if I trigger execution from the Test Suite console itself, when i complete the test steps, the accurate results are posted to the console, but if I trigger execution directly from the Test Case Execution record created from the Test Suite, when I complete the process and review the Test Suite console, the status for the associated test is NOT updated, as if i never performed the test.   Is this be design or is it something I have set up improperly in my document relationships?

Thanks for your guidance ... Rich VanDenburg

2 answers



permanent link
Stefan Schmelz (471819) | answered May 29 '14, 5:38 a.m.
Hi Rich,

a TCER is a planning instrument to define in which context (ie Testplan) at which specific time (Testschedule), on which environment (Test Environment) a specific Testcase with a specific Testscript is to be executed.
If you perform this execution, the Test Results are linked to the TCER and you evolve your planning instrument TCER into a tracking instrument.

Exactly the same for a Test Suite and its TSER.
With the only difference, that when executing the TSER the TCERs of the linked TC are executed one after the other, which match the context information specified by the TSER (Testplan, Test Schedule, Test Environment, Test Case). If a TCER matching this information does not yet exist, it is created. The TSER execution then links to the Test Case Result created thereby.

When you look at the results, in the Test Suite Result attached to the TSER , you will find the links to Test Case Results, which were created, when executing the Suite.
If you execute the TCERs independently, you create different results (ie Result IDs)

In a Test Plan you should therefore either only use Test Suites (because you need to reflect a E2E scenarios, in which an independent execution of single TCs do not make sense) or Test Cases, and differentiate between TCs executed under a Suite and TCs which are executed indepently.



permanent link
Reshma Ratnani (1.1k1) | answered May 07 '14, 2:20 a.m.
JAZZ DEVELOPER
Hi Rich,

Currently there is no way to find if the Test Case Execution records was created from TestSuite or TestCase.

Which version of RQM are you using?

Comments
Rich VanDenburg commented May 07 '14, 8:49 a.m.

Hi Thanks for your reply.  We have RQM version 4.0.5.  In my testing as stated above it seems the design is if a Test Case Execution record is created from the creation of a Test Suite Execution record, then you must trigger test from the Test Suite Execution record to ensure the proper status is in both the Test Suite Execution record and the Test Case Execution record.  It is unfortunate from a Test Management perspective, since all actual test execution occurs from the Test Execution record regardless of where it originates, to not have the ability to guide the tester to only the Test Execution record to perform testing for process simplicity, and have the result update all records that it is associated too for appropriate tracking and status to the canned reports.  You say that "Test Case Execution records was created from TestSuite or TestCase."  How is it when I trigger the test execution from the Test Suite Console - at completion it knows which Test Execution record to update ??  But the reverse is not known?   Thanks for you insight.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.