|Anonymous | Login | Signup for a new account||2020-09-29 10:33 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000674||TestLink||Test Specification||public||2007-02-26 20:49||2008-11-07 19:47|
|Product Version||1.7.0 BETA 5|
|Fixed in Version||1.8 Beta 1|
|Summary||0000674: Test cases id should be incremented by 1.|
|Description||Probably 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 Information||Duplicate 257|
|Tags||No tags attached.|
|QA Team - Task Workflow Status|
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.
my vote is forget this for a while
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).
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..
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.
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
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).
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
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?
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)
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.
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?
PS I'll try to have a look at the current implementation in version 1.8.
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.
|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|