test case versioning in RQM
My team has recently started using RQM, and we have a question about test case versioning. Some of our test cases may require modifications to the procedure, expected results, etc. for a new release. To keep track of these changes for each release, and to be able to test for multiple releases at the same time, we are going to use the following solution:
We have decided to use different test scripts for a test case for each release. We will also use different TERs for a test case for each release, and the TERs will be linked to the correct test environments, test scripts, and test plans for each new release. All written information for all releases will just be combined into the text editor sections (such as the Pre-Conditions and Test Case Design sections). We believe that this solution will work for us, but we wanted to make sure that this is how Rational intended for test scripts and TERs to be used.
Does anyone have any other recommendations for test case versioning in RQM? Is this how Rational intended for us to use the tool?
Thanks,
Madalina
We have decided to use different test scripts for a test case for each release. We will also use different TERs for a test case for each release, and the TERs will be linked to the correct test environments, test scripts, and test plans for each new release. All written information for all releases will just be combined into the text editor sections (such as the Pre-Conditions and Test Case Design sections). We believe that this solution will work for us, but we wanted to make sure that this is how Rational intended for test scripts and TERs to be used.
Does anyone have any other recommendations for test case versioning in RQM? Is this how Rational intended for us to use the tool?
Thanks,
Madalina
6 answers
My team has recently started using RQM, and we have a question about test case versioning. Some of our test cases may require modifications to the procedure, expected results, etc. for a new release. To keep track of these changes for each release, and to be able to test for multiple releases at the same time, we are going to use the following solution:
We have decided to use different test scripts for a test case for each release. We will also use different TERs for a test case for each release, and the TERs will be linked to the correct test environments, test scripts, and test plans for each new release. All written information for all releases will just be combined into the text editor sections (such as the Pre-Conditions and Test Case Design sections). We believe that this solution will work for us, but we wanted to make sure that this is how Rational intended for test scripts and TERs to be used.
Does anyone have any other recommendations for test case versioning in RQM? Is this how Rational intended for us to use the tool?
Thanks,
Madalina
I'm not sure what type of versioning you're looking for, but RQM support test case snapshot which can be use to keep older version of a test case.
My team has recently started using RQM, and we have a question about test case versioning. Some of our test cases may require modifications to the procedure, expected results, etc. for a new release. To keep track of these changes for each release, and to be able to test for multiple releases at the same time, we are going to use the following solution:
We have decided to use different test scripts for a test case for each release. We will also use different TERs for a test case for each release, and the TERs will be linked to the correct test environments, test scripts, and test plans for each new release. All written information for all releases will just be combined into the text editor sections (such as the Pre-Conditions and Test Case Design sections). We believe that this solution will work for us, but we wanted to make sure that this is how Rational intended for test scripts and TERs to be used.
Does anyone have any other recommendations for test case versioning in RQM? Is this how Rational intended for us to use the tool?
Thanks,
Madalina
I'm not sure what type of versioning you're looking for, but RQM support test case snapshot which can be use to keep older version of a test case.
I believe that snapshots are read-only, so you would not be able to run execution records for a test case snapshot. We're looking for different versions of the same test case that you can run when you're testing multiple releases at the same time. However, I think that we may end up using a new project area for each release in order to avoid this problem. Is this what other teams do - use a new project area for each new release cycle?
Thanks,
Maddy
I believe that snapshots are read-only, so you would not be able to run execution records for a test case snapshot. We're looking for different versions of the same test case that you can run when you're testing multiple releases at the same time. However, I think that we may end up using a new project area for each release in order to avoid this problem. Is this what other teams do - use a new project area for each new release cycle?
Thanks,
Maddy
Hello,
What version are you using. Looking "quickly" at our dev 2.0.1, there is a duplicate option on test cases. When you create a snapshot, you can create a copy of the snapshot as well. Do either of these meet those needs?
I believe that snapshots are read-only, so you would not be able to run execution records for a test case snapshot. We're looking for different versions of the same test case that you can run when you're testing multiple releases at the same time. However, I think that we may end up using a new project area for each release in order to avoid this problem. Is this what other teams do - use a new project area for each new release cycle?
Thanks,
Maddy
Hello,
What version are you using. Looking "quickly" at our dev 2.0.1, there is a duplicate option on test cases. When you create a snapshot, you can create a copy of the snapshot as well. Do either of these meet those needs?
We're using 2.0.1 iFix3. We've been discussing this issue, and I think we're going to create new project areas in RQM for new releases. For a new release, we plan on duplicating all of the test cases from the current release into a new project area. This should keep RQM clean for us, since a project area will only contain information for one release. This is similar to your idea, since you suggested that we duplicate the test cases anyway.
If you see anything wrong with this approach, please let us know. Otherwise, thanks for your help!
-Madalina
In my team we're having the exact same discussion. There are several ways the problem of multiple releases could be tackled, but none of them feels right. It seems as this issue was not thought of during development of RQM. It is of utter importance though, since we need to support the current release(s) which are in production at our clients sites and at the same time we have to develop the feature release and test it.
The duplicate function of the test case item is not sufficient. The test case will stay the same in most cases anyway. But duplicating a test case does not duplicate the associated script which is more likely to change from release to release. having multiple test scripts associated to a test case makes creation of TER's more complicated and means more work for each test iteration. Therefore we're thinking of using another project area although this will increase the general complexity of the tool.
It would be really nice to see RQM genuinely supporting multiple releases of a software. and also having some best practices on how to handle the releases.
The duplicate function of the test case item is not sufficient. The test case will stay the same in most cases anyway. But duplicating a test case does not duplicate the associated script which is more likely to change from release to release. having multiple test scripts associated to a test case makes creation of TER's more complicated and means more work for each test iteration. Therefore we're thinking of using another project area although this will increase the general complexity of the tool.
It would be really nice to see RQM genuinely supporting multiple releases of a software. and also having some best practices on how to handle the releases.
This is a very interesting topic. RQM is designed to facilitate reuse but a lot of the time what you want is reuse with changes (partial reuse?).
With the ability for test plans to share test cases which can in turn share test scripts. there are lots of options.
Previous approach with TestManager was to simply copy entire test plans then modify the structure and content as required. You can duplicate test plans in RQM as well but the new test plan "Copy of..." will contain links to the original set of test cases which in turn contain links to the original test scripts.
Using multiple project areas would completely defeat the reuse goal as well as creating administrative overhead.
How about a test plan for each release? Duplicate an existing test plan, open the copy and rename it.
This way, all the existing categories will be available for categorizing your test cases. With the multiple project area approach you'd have to recreate these each time.
If a test case is OK as is, you need to do nothing. If a test case needs to be modified, duplicate it and rename it. Remove the old test case from the new test plan and add the copy (and rename it). If required, do the same with the test script. To make things easier and less error prone, you could use a naming convention based on releases for naming the test cases and/or test scripts.
I haven't tried any of this. The proof of the cooking etc
With the ability for test plans to share test cases which can in turn share test scripts. there are lots of options.
Previous approach with TestManager was to simply copy entire test plans then modify the structure and content as required. You can duplicate test plans in RQM as well but the new test plan "Copy of..." will contain links to the original set of test cases which in turn contain links to the original test scripts.
Using multiple project areas would completely defeat the reuse goal as well as creating administrative overhead.
How about a test plan for each release? Duplicate an existing test plan, open the copy and rename it.
This way, all the existing categories will be available for categorizing your test cases. With the multiple project area approach you'd have to recreate these each time.
If a test case is OK as is, you need to do nothing. If a test case needs to be modified, duplicate it and rename it. Remove the old test case from the new test plan and add the copy (and rename it). If required, do the same with the test script. To make things easier and less error prone, you could use a naming convention based on releases for naming the test cases and/or test scripts.
I haven't tried any of this. The proof of the cooking etc