1. When it is advisable for a team to go a Test Suite creation in RQM.

Here are a few examples where test suites can be applied:

Build Verification Test: Consisting of a collection of test cases that do a basic validation of the majority of the products functional areas. These are executed after each product build before promoting the build for consumption by a larger audience.

Smoke Testing: A collection of test cases that ensure basic product functionality. Typically this is the first level of testing performed after changes in the system under test.

End-to-End Integration Test: Consisting of test cases that cross product boundaries and ensure the integration points between products are exercised and validated.

Functional Verification Test: Test suites can be used to group test cases that focus on a specific product function. By executing this type of test suite, it will ensure that several aspects of a specific feature have been exercised.

2. Can we separately create Test Execution Records(TER) separately for the Test Cases in a Test Suite without executing them as we do in case of Test Cases in Test Plan.
Yes, you can always create TERs for test cases independent of it's plan or suite. You can do this either from the main Construction menu or the TER section of the Test Case editor via the Generate TER wizard. The on thing to keep in mind is that if you do run a test suite that has test cases steps with no matching TER, then a TER will automatically be created for you. But if desired you could have created it manually before even creating the test suite.

3. Is it a good idea to create a test suite if we have large number of test cases , for example 50+ Test cases. Sure, it's ok to have such large test suites. But don't uses test suites as just a means of grouping test cases. The test suite should have a purposes similar to those mentioned above. Not just as a convenient way for you to organize your test cases.

4. Can we assign the Test Cases present in a Test Suite to more than one team member for execution. Ownership of execution is done based on the owner of the TERs, the steps in the test suite do not allow you to specify owner. Although the steps in the Test Suite will ultimately cause TERs to be created, ownership is not specified in the context of the Test Suite. Some customers have asked for the table in the test suite to actually be TERs not just case/script/environment combinations. But RQM doesn't provide this yet.

How are the TERs used for logging results selected per test case in a suite?

How are the TERs used for logging results selected per test case in a suite?

When you run a test suite, RQM will try to find an existing TER that meets the criteria for a given step in the test suite. For example, if you have a step in your suite that has a test case set to run on a particular environment. Then when the suite runs, RQM will try to find a TER for that test case in that environment. If it finds one then it is used for the test suite, if it doesn't find one then RQM will create a new TER that matches that environment and use it. The Test Case results that are produce by running the Test Suite will be associated with this TER.

Hi,

We are in the process of designing our setup for RQM. One of our team members is considering taking all of our Test Cases and their affiliated Test Scripts and breaking each one down into a set of Test Cases/Scripts which will become a Test Suite. Each current Test Case/Script will be broken-down into smaller, stand-alone Test Cases/Scripts as follows:
-- the login portion
-- an iterative (looping) portion
-- a non-iterative (sequential) portion
In this design, a Test Suite will contain the login Test Case/Script, and any number of iterative and non-iterative Test Cases/Scripts that constituted the original Test Case/Script.

Can we have your feedback on this design?

Many thanks.

This seems like a misuse of Test Suites. It seems that you are trying to use the Test Suite as a means of working around a shortcomings that RQM has with respect to looping over a portion of a test script.

I'm guessing that the something changes for each iteration of the "looping" portion. Likely some data that is being references from an RQM Test Data. A common complaint is that RQM doesn't allow you to only loop over a portion of the script. Instead you have to loop the entire script. In your case that would also include the "login" portion and the "sequential" portion. But you really just want to iterate over the "looping" portion.

Currently RQM doesn't support that, but it seems like you are trying to achieve it through the use of Test Suites. That will get you the execution behavior you are trying to get, but that's not what Test Suites where designed for. Seems like you want to do this on a wide scale and I would proceed with caution. Be sure to evaluate how you plan and report on such test activites, as the reporting around test suites is not on par with that of test cases (yet). Also, the "login portion" is a prime candidate for a keyword. In which case it isn't it's own test case, rather a set of steps that can be shared between different test scripts.

FYI, the enhancement request asking to only loop over a portion of a script is here:

https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/49950

Hi Kurtis,

Is this the right work item?  It looks like this is for omitting certain script steps and not looping through them.

Thanks,

Rob