Mantis Bugtracker 

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000674TestLinkTest Specificationpublic2007-02-26 20:492008-11-07 19:47
Assigned Tofman 
PrioritynormalSeverityfeature requestReproducibilityalways
PlatformOSOS Version
Product Version1.7.0 BETA 5 
Fixed in Version1.8 Beta 1 
Summary0000674: Test cases id should be incremented by 1.
DescriptionProbably the same sequence is used for numbering other thing. I think that a Test Case Id should reflect the number of test cases created so far.
Additional InformationDuplicate 257
TagsNo tags attached.
Database (MySQL,Postgres,etc)
PHP Version
QA Team - Task Workflow Status
Attached Files

- Relationships
related to 0000257closedfman Test case Numbering unique to product. 
related to 0001200closedmhavlat When a test case is created ID gets incremented by 2 

-  Notes
fman (administrator)
2007-02-26 21:27

Sorry what seems simply sometime is not.
IMHO this is not important, just a matter of custom.
TC 444444 or 1 is the same.

May be in the future we will add some sort of external ID, that will behave as you ask, but for the next release to come this is not IMHO a important feature.

@ Team
my vote is forget this for a while
fman (administrator)
2007-02-26 22:13

@ Team
Because we don't have (we have removed it) a test case table, think one
alternative can be add a new field on tcversion table (something like TCNUMBER).
2007-02-28 05:54

I think this would be OK. adding a TCNUMBER to the TC version table. I have been thinking about this functionality for a while,, and while I agree, 44444 really is the same as 1, there is a cosmetic aspect to having unique numbering per test project.

I would solve it this way, by adding a new column to the nodes_hierarchy table,
for the testcase types, it would contain this unique ID for the testcase,
and for the testplan types, it would contain a three letter identifier for the test project..

For Example:
Test Project: Shopping Cart
would have a 3 letter identifier like SCT or CRT, or something like that.
then each test case for this test project would have a TC id of CRT-1, CRT-2, etc.. ( this is how JIRA numbers it's issues )

so the testcase ID can readily be associated to a test Project..
For groups like mine that have over 50 different test projects defined, this would be a great feature to have.
fman (administrator)
2007-03-03 17:11

Needs more Team discussion, but initially don't like using new id field on Node hierarchy.
If needed I will prefer to add on Testplan also.
Anyway we will return to this after 1.7.0 stable
mhavlat (reporter)
2007-09-24 04:48

IMHO not reason to modify DB because of this. Everybody can use title for adding such identifier.
I've used for example title "TL-GENERAL-3" for some my previous projects. TL is name of product, continue a feature and numbering.
Or user can use numbering with title: "56 Delete all test cases" or "TL57 Delete all test cases". For this second way somebody can implement a feature that automatically add a number into title (based on previous TCs within Test Suite).
fman (administrator)
2008-01-14 18:01

Development started:

for each Testproject:
a prefix (string of 3 char max) must be defined
a test case counter is defined

External test case id (what users see) if created in this way:

prefix . glue_character . test case counter
pvmeerbe (reporter)
2008-01-26 00:16
edited on: 2008-01-26 00:26


Apparently mhavlat already suggested my proposed system in id 000257.



I stumbled upon this entry in mantis in my search for a full traceability solution by means of a test case 'external id'. Please point me to the correct spot if this isn't the right place to discuss this.

Perhaps the current implementation idea can be extended to allow the following setup : In our test projects we use unique identifiers from test requirements over test cases till reported bugs to allow full traceability. Our requirements are modeled in a Feature to test hierarchy ( FTTH) organized a bit like the testlink hierarchy tree with test suites. See the dummy example below this note which also includes some test cases.
Perhaps a small explanation is useful :
- Each requirement has a unique id reflecting the path from the top (i.e. the product or test project) untill the requirement itself, for example the P1_UPD_CN (product P1 , sub feature updating, requirement check for new update).
- Each requirement generates test cases which have themselves an id based on the the one of the requirement, for example P1_UPD_CN_01 and P1_UPD_CN_02 .
- Finally This test case id can be mentioned during defect reporting in the bug tracking tool.

This setup allows traceability from requirement to defect reporting.
A reverse traceability can also be performed from the defect report towards the requirement.

Adding a new column to the nodes_hierarchy table seems a logic solution for this setup since test cases, test suites & test projects have a useful value for this new column. The value of the columns should be editable using the testlink gui allowing full flexibility. I know that one can simply add this unique id to the title but it seems more logic to have both the description and id in a seperate database field in case only the id is needed in a lookup. Adding a custom field also allows this, but this custom field isn't shown in the user friendly tree structure of test cases in the testlink gui. What do you guys think?

kind regards


Example :

product 1 (P1):
|__ updating (P1_UPD)
| |
| |-- requirement 1 : check for new software (P1_UPD_CN)
| | |-- test case 1 : check for new major version (P1_UPD_CN_1)
| | |-- test case 2 : check for new minor version (P1_UPD_CN_2)
| |
| |-- requirement 2 : install new version (P1_UPD_INS)
|__ networking (P1_NET)
| |
| |__ requirement 3 : configure (P_NET_CON)

fman (administrator)
2008-01-26 00:32

Please read related issues.
We can consider your ideas in future, but right now TL 1.8 will have TestCase external ID that will be unique inside testprojects.

relationship between Requirements and Testcase can be achieved using existent TL feature.

Initially do not like adding new column to nodes_hierachy that will not be used for every type of node.

Please review your proposal using this new info.

You can get TL 1.8 and give a look to external id implementation.

pvmeerbe (reporter)
2008-01-28 16:44

Hi fman,

I've read the other posts (00257 & 0001200).

The relation between requirements & testcases can indeed be found when using both functionalities in testlink. However we are currently not using the requirements functions of testlink. I find testlink a fantastic program regarding the test case management & reporting. However I'm missing some functionalities for requirement management in it. (we start breaking down our project/product in a graphical presentation with all features; then a feature to test hierarchy is created from it including risk analyses/priority/test level/test technique/ ...).
Hence we are currently using a different system for the requirement management and need a reference between this system and the tescase management of testlink.

I do not completely understand your comment on not using the proposed new column for every node. If I understand it correctly only a test plan node will not use this new column (test project, test suites & test cases will). IMHO the test plan node is already a special case for this table.

Perhaps a small adjustment in the implementation you are currently creating can solve my problem : I can implement my coupling if you allow modification (i.e. manual overruling of the automatic naming system) of the external test case id field from the testlink GUI (perhaps with a config option in the background). This would probably required additional duplicate validation. Perhaps in a first version without the validation.

What do you think? Could this be possible?

kind regards
PS I'll try to have a look at the current implementation in version 1.8.
fman (administrator)
2008-01-28 16:53

1. Try to solve your problem adding a custom field on TEST CASES where you can write YOUR desired ID.
2. you can do search for CUSTOM Fields
3. Let me know
4. For 1.8 this will be standard implementation.

- Issue History
Date Modified Username Field Change
2007-02-26 20:49 Philip New Issue
2007-02-26 21:27 fman Note Added: 0001354
2007-02-26 22:13 fman Note Added: 0001356
2007-02-28 05:54 jbarchibald Note Added: 0001382
2007-03-03 17:11 fman Note Added: 0001435
2007-03-04 08:07 schlundus Category Test Specification => New Feature
2007-09-24 04:48 mhavlat Note Added: 0002216
2007-09-25 23:25 fman Relationship added related to 0000257
2007-11-14 16:48 mhavlat Severity trivial => feature request
2007-11-14 16:48 mhavlat Status new => acknowledged
2007-11-14 16:48 mhavlat Category New Feature => Test Specification
2007-11-14 16:48 mhavlat Additional Information Updated
2007-11-22 17:38 fman Relationship added related to 0001200
2008-01-14 17:59 fman Status acknowledged => assigned
2008-01-14 17:59 fman Assigned To => fman
2008-01-14 18:01 fman Note Added: 0002934
2008-01-26 00:16 pvmeerbe Note Added: 0003072
2008-01-26 00:26 pvmeerbe Note Edited: 0003072
2008-01-26 00:32 fman Note Added: 0003074
2008-01-28 16:44 pvmeerbe Note Added: 0003097
2008-01-28 16:53 fman Note Added: 0003098
2008-01-28 16:54 fman Status assigned => resolved
2008-01-28 16:54 fman Fixed in Version => next development version (1.8 Beta1)
2008-01-28 16:54 fman Resolution open => fixed
2008-06-03 16:48 mhavlat Fixed in Version next development version (1.8 Beta1) => 1.8 Beta 1
2008-11-07 19:47 mhavlat Status resolved => closed

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker