Cutomized TestCaseID.

[krishnas]

Hi,
Thanks for the wonderful tool Testlink.
Currently TestCaseID (TCID) is a unique autonumber field which increments automatically irresepective of product or component.

I wand to implement a custom TCID field something link
ProductName+ComponentName+TestCase ID Specific to component.

How can I do this Please suggest.

I am using TestLink 1.6.2.

Thanks in advance.

[fman]

Is very difficult for me understand why is important to have progressive ID inside a product.
IMHO has no value.

My advice, anyway is not to add a single line of code to TL 1.6.x, because
all our efforts are on TL 1.7, then upgrade to 1.7 and create a patch if you want

Regards

[drew]

It's important so that you can track the test cases, between multiple databases, products, and departments. Lets say you have a database of test cases with ID's the way they are assigned in Test Link, and you have a group of people who are working on automating the test cases. But then as you create a new product you have to copy the test cases from the old product to the new one, as the new one will have additional test cases for the new features. Now you have a list of test cases that you ran against version 1 of your product, and a new list with some of the old test cases, some new test cases and some of the old test cases removed for version 2 of the product. Since you now have a completely different ID# for the same test case in two products you have no way of keeping track of them both (other than by name) And now the people automating the test cases don't know if the cases they automated are the ones in the new product, or the old one, or both, or neither. Now when version 3 of the product comes out you are going to have a whole new disconnect between the versions. Because now with the current ID numbering scheme in Test Link you will potentially have 3 copies of the same test case across the products with three different ID# and no way of telling if it's the same test case.
That's why you need to restart the test case numbering for each product, or at least offer that as an option when the user goes to copy the test cases. Either that or a unique field in the test cases itself that will allow to assign test case ID # in a variety of ways.
Bottom line is it offers the people using test link much more flexibility with the product and helps them fit test link to their needs, instead of having them tailor their needs around test link. It seems that this is very commonly requested feature, and I would like to have it too.

[fman]

I undertand but ... , think best solution is add a USER MANAGED CODE as name prefix, then you can manage as you want.
OK you need to keep track of last number used.

Making the kind of change you are asking for is not easy, because means to rethink part of DB SCHEMA.

May be in the future.

Just for the record:
Do you know how is manage this issue on:
TestDirector, Salome or qa-trac ?

Regards

Francisco

[drew]

Hey fman I have not been around for a while, however I gave some thought to adding an extra test case field and have actually implemented it in my 1.6.3 testlink version. In the end it turned out to be pretty simple and did not require much database restructuring. I simply added a new column to 'testcase' and 'mgttestcase'. I added the new field to the appropriate templates, and then went through the functions controlling those templates to store and the relevent information to those db fields. I now use the field to insert any custom ID number into a test case, and I can edit that ID number if I need to. (the automatically assigned TestLink ID's remain unchanged). For personal use reasons I've descided to make the cutom ID's not auto-incremented.
This way I'm able to track test cases even when I copy/move them between products and the Test Link ID's change.
I'm not sure if this is something that you'd actually want to ever implement in the release version of TestLink, but at least the consept has been proven possible. Let me know if you are interested in any more information.

[fman]

I think the solution you have choose is the natural one, and time ago before starting 1.7 development we (the dev team) have some discussion about what i think is an EXTERNAL id.

Think in the future we will add this feature on 1.7.

I appreciate if you want to send us a document with details about your
implementation, you think can be useful for us.

regards