|Anonymous | Login | Signup for a new account||2019-10-17 04:02 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000257||TestLink||Test Specification||public||2005-11-28 22:12||2008-11-07 19:47|
|Fixed in Version||1.8 Beta 1|
|Summary||0000257: Test case Numbering unique to product.|
|Description||This is a feature of JIRA, that would be really cool to implement into TestLink.|
when setting up a Product, one would define a 3 letter prefix for the test case numbering. Then when creating test cases, they would be numbered <prefix>-1, <prefix>-2, etc..
right now, when I am adding testcase to my product. I may get Tc-ID 500, and my next new Testcase may be tc-ID 850, because it got added after another did a massive import for a totally different product.
Under this unique numbering. productA could have ID's PRA-1, PRA-2 , and ProductB could then have PRB-1, PRB-2.
There would just need to be validation that this same 3 digit code is not duplicated across product.
I would be glad to take this on as well..
|Additional Information||This would entirely be for display only.. the intenal ID would still be used for tracking and reference to testcase table. but definitly makes the test case numbering more professional...especially for reporting. |
I was thinking maybe we could add a two columns to the mgtproduct table. One for the Short Name, and the other the last ID_Number used for that product.
then a new column added to the mgtTestcase table that would be say, displayed_TCNum. and would be updated from the information on the mgtProduct table upon insert.
Or - a possible simpler way to do it would be to add a single int column to the mgtTestCase table, we could then to a max(dispayed_TCNum) for prodID=1, to ge the next number for insert, and for display, we could easily cache the prefix info from mgtProduct, like the prod ID, and then build this unique TC number at display time, in the Templates
Does this seem like something others would like to see?
|Tags||No tags attached.|
|QA Team - Task Workflow Status|
We have started on Team a discussion about something similar.
I call it EXTERNAL ID, or something like that.
I will add you ideas to our discussion.
Does custom fields functionality help to solve it?
We could add another string into TC table. Configurable as optional visibility. Would you like to develope it then?
Custom fields does not really solve this issue. we would rather have something that is assigned by the system automatically and not really editable by the user.
I'm not thinking custom fields can do that..
I would love to work on this,, I'll post as soon as i have something complete and working.
|Please do no start any development without submitting an spec about the feature.|
Editable identifier for TC will have an extra string field in DB per test case. The value must be unique within Test Project.
The idenitifier is disabled as default. (Configurable in config.)
Automatic filling: Create TC offers an automatically generated value in the field. The value consists from prefix (defined by parent Test Suite) and number. Number should be equal TC count in parent TSuite + 1. (or something better) A TC create fails if prefix is empty.
Test Suite have an extra string field for a TC prefix.
--- Req 1:
--- Editable identifier for TC will have an extra string field in DB per test
there is not testcase table. This field must be added on tcversion table
--- The value must be unique within Test Project.
one new field must be added on testproject table, some sort of counter or id
that contains last tc id created
--- Req 3:
--- Automatic filling: Create TC offers an automatically generated value in the field.
--- The value consists from prefix (defined by parent Test Suite) and number.
--- Number should be equal TC count in parent TSuite + 1.
Not clear, if tc numbering must be unique inside testproject, the number
must be generated using new field on testproject
--- (or something better) A TC create fails if prefix is empty
Disagree, must be configurable -> then TC numbering msut be unique inside
test project, and not created counting tc on testsuites.
if you use Tsuite prefix on names, changes must be done on the copy
Same applies to testcase move
Think best thing is start generating an OpenOffice doc with analisis
I suggest to ad a new DB field (100 chars) to node.
Test Suite should be used as prefix clarification as shows an example:
Project prefix: TL
Suite prefix: TL-API
Test Case CID: TL-API-1, TL-API-2, etc.
Suite prefix: TL-GENERAL
Test Case CID: TL-GENERAL-1, TL-GENERAL-2, etc.
Suite prefix: <missing>
Test Case CID: TL-1, TL-2, etc.
CID = Custom ID
Implementation is up and running.
No new field added to node table , because will be useful just for testcases,
because for testplan, testproject, testsuite (at least IMHO) prefix in not useful, because it ID are never needed (are needed just for API).
managing a TSUITE prefix add just a new parameter to configure and new checks to assure uniquines configuration.
See a lot of complexity in using two prefixes.
Think this feature must be tested as is developed now, and after evaluating if
is or not enough do other changes.
Having just two prefix of 16 chars will means a lot of screen space in
every place where you need to display testcase ID, may be adding redundant info.
Other issues are prefix changing on testsuites that will have impact on external testcase id.
new field added to tcversions table (tc_external_id) (numeric)
prefix is NOT SAVED in tcversions but getting from testproject.
This solution makes simple the operation of changing a testproject prefix.
Please give a change to actual implementation.
Think that this first version will be enough to give users what were requested.
No problem. I didn't know that you developed it already.
Anyway, I've expected that if CID is used (ID is not visible).
Just wondering if this feature will be implemented as mhavlat suggested here on 01-15-08 ? If so what is the current status?
fman seems to suggest a different implementation only allowing a prefix for the test project and not for the test suites in mantis id 674 (http://www.testlink.org/mantis/view.php?id=674#bugnotes [^])
Implementation use only prefix for TestProjects and nothing more.
Raw details of implementation are present here (note 2951).
This will be implementation to be released with TL 1.8 Beta 1
I'm probably missing something since I can't seem to find note 2951 here to which you are referring to (it jumps from note 2947 to 2953), nor a possibility in mantis to jump to a specific note. Can you give me additional instructions on how to view this?
|note 2951 is here in this issue|
Even a search in Mozilla for 2951 on this page doesn't give me the message. Could it be that this message is only visible for certain persons or with specific access rights? it jumps from note 2947 to 2953 when I view this issue ...
|The note was private. I just made it public so everyone should be able to see it.|
|2005-11-28 22:12||jbarchibald||New Issue|
|2005-11-29 08:00||fman||Note Added: 0000404|
|2007-02-19 23:23||mhavlat||Project||Testlink 1.6.x => TestLink|
|2007-09-16 05:15||mhavlat||Note Added: 0002151|
|2007-09-16 05:16||mhavlat||Status||new => feedback|
|2007-09-17 23:08||jbarchibald||Note Added: 0002167|
|2007-09-17 23:14||fman||Note Added: 0002168|
|2007-09-25 23:25||fman||Relationship added||related to 0000674|
|2007-11-13 17:57||mhavlat||Note Added: 0002667|
|2007-11-13 17:58||mhavlat||Status||feedback => acknowledged|
|2007-11-13 17:58||mhavlat||Category||New Feature => Test Specification|
|2007-11-13 18:25||fman||Note Added: 0002668|
|2008-01-14 18:02||fman||Status||acknowledged => assigned|
|2008-01-14 18:02||fman||Assigned To||=> fman|
|2008-01-16 01:25||mhavlat||Note Added: 0002947|
|2008-01-16 02:48||fman||Note Added: 0002951|
|2008-01-16 03:09||mhavlat||Note Added: 0002953|
|2008-01-26 00:31||pvmeerbe||Note Added: 0003073|
|2008-01-26 00:33||fman||Relationship added||related to 0001200|
|2008-01-26 00:35||fman||Note Added: 0003075|
|2008-01-26 00:51||pvmeerbe||Note Added: 0003079|
|2008-01-26 00:58||fman||Note Added: 0003080|
|2008-01-26 01:05||pvmeerbe||Note Added: 0003082|
|2008-01-26 01:06||azl||Note View State: 2951: public|
|2008-01-26 01:07||azl||Note Added: 0003083|
|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 - 2019 MantisBT Team|