|Anonymous | Login | Signup for a new account||2019-12-13 14:25 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007095||TestLink||Custom fields||public||2015-04-28 09:14||2015-04-29 10:35|
|Product Version||1.9.13 (2015 #1)|
|Fixed in Version|
|Summary||0007095: Allow custom fields to be added on a per-test-case basis|
|Description||I very much like the concept of the custom fields, as it gives us the possibility to use them as containers where test data to be used can be communicated to the tester or require them to document certain key test data.|
My grasp of the feature is that they can be assigned on a test project level and if assigned, are available to all testcases/-plans in that test project. It is not possible to assign different custom fields to each individual testcase according to the requirements of the individual testcase.
Testcase A checks whether a document is created correctly as a result of a billing process. I create a custom field for the document# and set it as required to force the tester to document the number created in the execution of his test case.
Testcase B checks whether the user can correctly log in to the system.
Now, the tester that tests B is required to document a doc# that is not created/used in his testcase. Custom field for doc# is not necessary in testcase B.
My feature request:
Enable custom fields to be used in more fine-grained way, so that the test designer can choose and assign those custom fields to his testcases based on the individual documentation or data provision requirements of his testcase(s).
|Tags||No tags attached.|
|QA Team - Task Workflow Status|
edited on: 2015-04-28 17:15
Custom fields are intended as an extension to DB SCHEMA, then has to be applied to occurences of same entity, in this case Test Cases.
This is the way other systems work.
Level of configuration that you are requesting is too complex IMHO, then do not fit in current product roadmap
edited on: 2015-04-29 06:49
Personally, i think that the problem with the custom field feature in regards to its combination with testcases at the moment is that the concept is a very good one, but its potential can unfortunately not be used completely because of missing configuration possibilities.
In other cases, e.g. testplan, testsuite, build etc., i think it is sufficient, as with these objects i can not think of the requirement to individually assign custom fields. With testcases however, it is a different story, since they do have individual requirements regarding test data and documentation, because testcases tend to be very different from one another.
In my example, if i set custom field doc# to required, it would force the tester of testcase B to enter a doc#. In consequence, i can not set the doc# to required, so the feature can not be used.
I do not know how the feature is implemented, but my thoughts on how this could be resolved would be to introduce a dynamic linking table that contains the testcase ids, (most probably testcase version) and the assigned custom fields, e.g.:
TestcaseID | CustomFieldName
TC_A | doc#
TC_A | billingDate
TC_B | loginUserName
- Upon creating a testcase, the available custom fields for the testcase are read and presented to the user from the now existing config/db source (cf assignment to the testproject). The user selects the custom fields, he/she wants to add for this. Upon save, the dynamic linking table is updated with the custom fields selected for this test case.
- Upon displaying/executing a testcase, the dynamic linking table is queried. Based upon the information in there, the assigned custom fields can be displayed and further actions/checks as defined in the custom field definition can be executed dynamically based on the assignment in the linking table. This way, the field doc# would only be displayed and the required check would only be performed in testcase A.
Yes, it is a complex configuration, and yes, there are more points to consider (unassigning custom fields on a testproject levels etc.), but sometimes features have to have complex configuration possibilities in order to be used effectively. By implementing a scenario like this, the feature would become very flexible. It would be a main differentiation point against other tools. Also i think that the solution with this linking table is very straightforward.
Thanks again for commenting. I will be watching this issue closely, because I view it as a very important one. If you would like to discuss this in further detail or have any questions, I am more than willing
to share my thoughts.
|2015-04-28 09:14||rodak||New Issue|
|2015-04-28 13:48||fman||Note Added: 0023244|
|2015-04-28 17:15||fman||Note Edited: 0023244||View Revisions|
|2015-04-28 17:15||fman||Note View State: 0023244: public|
|2015-04-29 06:28||rodak||Note Added: 0023253|
|2015-04-29 06:31||rodak||Note Edited: 0023253||View Revisions|
|2015-04-29 06:47||rodak||Note Edited: 0023253||View Revisions|
|2015-04-29 06:49||rodak||Note Edited: 0023253||View Revisions|
|Copyright © 2000 - 2019 MantisBT Team|