Upgrading HPE ALM/QC has always been a source of dread for administrators. It’s a process that typically involves significant planning and meetings, discussion, more meetings, more discussion, more planning, and on and on. Everyone wants to get it right, but few are comfortable with the process. It is very understandable then that most administrators want to take the time to do it the right way to avoid issues and downtime. Our discussion today is about a couple of issues that could occur after an upgrade that was done 100% correctly. Yes, you read that right. A 100% proper upgrade could still present you with some hidden issues after the fact.
The preferred method/process is to stand up a new server, get ALM installed, and start the progress of migrating your existing projects and upgrading them, one at a time. While this is considerably more effort than doing an in-place upgrade, this method prevents data loss and downtime for issues. It’s more of an “upgrade at your leisure” and frankly is the better approach for upgrading ALM.
I am not here to detail the upgrade process for said migrations, though. Instead, I am here to tell you about a couple of hidden issues that could arise from migration upgrades. These issues are not documented by HPE in any significant detail so most administrators are completely unaware that they need to check on these concerns post upgrade. These issues too are rather random in occurrence and do not plague every upgrade. While the exact reason isn’t something HPE has been able to define, it does seem to “mostly” affect upgrades from lower versions of QC and ALM (9.x, 10, 11.0) that moved to 11.52 and then up to 12.x. That said, it could occur in newer installations with just one upgrade, so don’t rule yourself out as there is no information at this time as to the cause.
Well enough introduction, let’s get to the meat here.
Hidden issue #1: Custom user groups can get corrupted during the upgrade process.
This issue is getting to be quite common these days. You finish your upgrade; you complete a project migration and upgrade, verify and repair works. You log in to the project, create a requirement, create a test, run it, create a defect. Project seems fine so you turn it loose to your users. And then the issues start rolling in. Users can create some tests, or open defects, or edit some fields. You enter customization and check your user group permissions. Everything is checked, so what gives?
The issue is that the custom user group you have in your project has a corruption from the upgrade. Even though the permission boxes are checked, users can’t do what the checks say they can. The most common source for this seems that these custom user groups did not use tdadmin as the base when they were created. Default groups such as Developer or QA Tester were instead used to create the custom group. While these groups worked fine in say ALM 11.52, they no longer function correctly in ALM 12.50. Your custom user group is now corrupt.
The only fix is to create a new group in your current ALM version and delete the older upgraded one. Now let me add this fact. Though HPE documentation hasn’t really been updated to stress this, let me stress this: You must use tdadmin as your base for any custom group creation. Yes, this is more work when you have to remove down permissions, but it has been well proven and commented on by HPE support that custom groups moving forward should only use tdadmin as the base for creation.
Custom groups based on tdadmin seem to upgrade without issue. Again, few administrators know the full history of things in ALM, so if you see checked permissions not working correctly in your custom user group, it’s a good idea to create a new one using tdadmin as the base. That should resolve any user issues where they have problems performing tasks that presented no concerns prior to the upgrade.
Now that you know about issue 1, let’s talk about issue 2.
Hidden Issue #2: Report Templates can get deleted during the upgrade process.
Issue 2 is not as common as the corrupt user groups, but it is a fairly commonly occurring one as well. HPE is aware of this one as well, but like the other, this one seems even more random as it does not affect all or even most upgrades. Exact reasoning as to why is not yet determined by HPE.
This issue requires a little more effort to discover as well as to fix. While it can be seen from the Dashboard > Analysis View project reports, more often it is discovered when trying to generate one of the default project reports that live under the Analysis tab options under specific modules such as Requirements, Test Plan, Test Lab, and Defects.
For our example, let’s go under Test Plan, click on Analysis menu option, then Project Report, and select “Tests with Design Steps”.
You might see an error come up such as this one.
Or perhaps like this one below.
The next logical step would be to then check the QC logs and find the error and get the full stack trace with details on the error.
The errors all have very common stack traces. You will tend to find the same error as your pop up, and then typically the repository path where the expected file (report template) should exist. Also further down in the stack trace there will be a listed path with the exact template name in it.
Example logs:
And
And
You can see the repository path is shown where it expected to find the file but could not, and in the second box is listed the exact name of the template that was to be loaded but could not be found.
The fix here is to replace the template from a working project. The best approach is to generate a new blank project in Site Admin and use that to grab the templates you need and replace them in the project with issues.
First, in your project with the error, enter the customization settings and then click on Project Report Templates on the left hand side. This will show you the full list of Project Report Templates. You will want to expand every folder and click on each template listed. When you click on one, the Details page loads to the right. For a working (and thus found) template, the Template Outline will show you a picture of what the report should look like. Typically reports that cannot be found will show as an X or will fail to load this preview under Template Outline. Click on each template and note each one that fails to load. These will be the ones you need to replace. Every time I have seen the issue of project report templates going missing after an ALM upgrade, the issue has always involved multiple templates and never just one or two. Be sure you take the time to check on each template from the list.
Below is a picture of a “working” template. Right on bottom shows the preview Outline whereas as a missing template would not be able to illustrate that.
Once you have identified each missing template, you will need to log in to Site Admin and create a new blank project. After creation, in a new IE session, log in and enter customization, then click on Project Report Templates.
For each project report template you are missing, find it in the list and click on it. You should see it in the preview with no problems. At the top in the menu bar are options such as Add Template, Delete, and so on. Use Download Template and download a copy of each template that you noted for your original upgraded ALM project. Once all are saved (keep the same default name), you will then want to go back to the Customization of the original project and use the Upload Template option to upload each template.
You should be able to replace the existing one or delete the original as needed. Once all are replaced, the error should no longer occur and users can generate reports just fine. Problem solved then.
Conclusion
Today we went over 2 “hidden” issues that won’t show up in upgrades, verifies or repairs. These issues won’t plague every upgrade or every customer, but they are annoying side effects that will need correction if they arise. HPE does not at this time have any official documentation on these issues primarily due to the random nature of their occurrences. For the time being, this write-up can hopefully server has a reminder of a couple of extra things to be aware of after an ALM upgrade.