Handling Post failure with QC Requirements in C#

Yesterday I covered creating new requirements and updating custom fields. Today I will discuss post failure and why handling it is non-trivial.

Quality Center has a requirement that no two requirements share the same name where they have the same parent. If you attempt to save a requirement like so using the QC UI it gives you an error and the user tries again. If you try using C# you get a COM Exception.

It also resets your object.

I couldn't believe it either. It means you can't add an incremental counter to the test case name and try posting again until it works. It means that if you are building your requirement up from a source document, you have to go and redo your work. This is a pain if you were using recursion.

There is a solution. It is not complicated either. What I did was to define a new class called SafeQcRequirement which owns standard QC requirement object and each of the attributes that you care about. In a worse case scenario you are duplicating all of the attributes. In my case it was only a handful.

As you build up your requirement, store all the data in the safe requirement. When it comes time to post, build the real QC requirement and post. If it fails, rebuild again with a new name try again. Keep going until you succeed.

The following screenshot is what my post routine resembles.

code in a bitmap, hideous... apologies... a solution is almost here.

The second protected post method is a recursive loop that just tries until it succeeds. There are no gaurds for stack overflows or more than uint requirements. Based on my usage scenarios this is unlikely. If it does occur, shotgun not testing.

In actual fact, any duplicate requirement names are recorded and fed back to the User Centered Design people (who created the source document) and they update their source document so that the duplicates no longer exist.

Regarding the exceptions: you don't get a useful exception from COM, so just capture the base exception and use the message text to determine if it is the one we care about.

Our requirements are sourced from an Axure document and in the next week I'll put a post about parsing their document for requirements. Tomorrow I'll cover adding attachments to requirements which is fairly trivial but there are still a few gotchas.