Test Plans - Copy from project A to project B - UDF fields
Everything I read about copying test plans from one project to another states that the projects need to be identical or else any mismatching User Defined Fields (UDF) will or can cause issues. I understand this, but our organization has a very large need to do this. Our projects per department have a need to define their own separate UDF's, so we are never going to have projects matching identically. We recently upgraded from QC 10 to ALM 11.52 and from Oracle to SQL database. Does anyone have a solution for this feature?
If you can export the tests to an appropriate Excel format, then you could use the Excel Add-in to import the tests into the destination project. That would allow you to edit the data to remove UDFs that don't apply to the destination, and map other UDFs where the underlying database columns don't have the same name.
(Opinions and information contained in this post are wholly my own and do not reflect the opinions of my employer.)
Thanks for your quick response. How labor intensive would that be? I am talking about hundreds, maybe thousands of test plans some times. We basically have a centralized 'REPOSITORY" Domain that contains our test plans and they move them between Departmental Domains and vice versa. I do not have much experience with API's or the OTA, but is anything like this possible? I would think basically I would need to check the SYSTEM_FIELD table to see if I have a match and copy if I do and bypass if it does not match. (SF_COLUMN_NAME, SF_COLUMN_TYPE, SF_USER_LABEL, etc...) Again, can you see any of this being possible? Thanks
We did pretty much exactly that for several hundred projects which probably equated to several million tests and requirements. It took a few months.
I built macros to extract the fields in use for each project as well as only the list values that were being used (no point mapping something that wasn't in use. This also told us if a field was in use or not). We then mapped from the old project to the new template both for fields and lists and extracted the data into excel in a format compatible with the new template. We then ran macros to replace any old list values with new ones and uploaded to ALM. I didn't use the excel add-in to do the upload, instead I used my own macros which supported test templates and html and saved the new id of the test or requirement so that we could restore coverage information. We also migrated defect data for some teams. All execution data was archived as was anything in the release module.
The issue is not the number of test cases or requirements you have, but the number of different projects you need to map to the new template. Test and requirement numbers impact duration, the API is slow, the number of projects with different customisations is what kills you when it comes to effort.
For projects with BPT or automated scripts we actually upgraded the projects to ALM via QC 10 and the used SQL to move data between fields to align with the new template and then copied them over to an empty project so that we didn't carry over unwanted tests, execution data, etc.