a nice feature to have that is missing

[tltp00]

Here a feature that is useful:

Ability to assign a "configuration" to a test case. A test case is created once but it can be run under multiple configurations. For example, running a test case on windows XP or Linux results in 2 result records.
The current workaround is probably to create multiple "test plans" or duplicating test cases. Not practical though.

Any other possible workaround? Thanks

[havlatm]

It's similar to requirement "platform" parameter for test execution. Could you describe a scenario how an user can add and get the information you missed?
Thanks.
Martin

[tltp00]

In the context of the current Testlink implementation, here is one possible scenario:
1. create a test case under Test Specification section
2. create some test configurations under a new Test configuration section. This will create a configuration of multiple parameters, i.e., ConfigA: Win xp + German + 2 Gig mem; ConfigB: Linux + English + 1 Gig mem
3. Add the test case to the test plan
4. Assign the test case to one or many configurations
5. Create a build number
6. Run Execute Tests. The filter allows to select a build number and a configuration. Mark the test case pass or fail as usual
7. run results query based the build number and/or configuration

[havlatm]

I understand. However it means significant change in architecture of test execution functionality. In addition we must remain the current behavior too.

I think that the easiest way it to add one more field to a build and create report which can integrate all these configuration with one build together. But I'm not sure if such solution will be enough.

[fman]

Please Checkout last CVS and try custom fields to see if can solve
your needs

let us know.

[shirlc]

Hi all. thanks for a great tool btw. i also have the same needs as this user. We tried out the custom fields and it doesn't seem to work as we expect it to based on how one sets it up. you seem to let us choose enable for testsuite and enable for execution. So we thought that one can define a bunch of test cases in a suite and then when we set up the test plan we thought that we could choose the test suite and then define the environment with custom fields that we have selected at the suite level. It seems the custom fields can only be defined and modified at the test case level upon execution. This requires a user to select the same thing for every test case in a suite when the run the test case which can get kind of time consuming although it is a work around.

Also the choice one have for the custom fields is kind of confusing we found that you can basically define the following things:

- testcase custom fields that can be display and modified during test case specification and displayed only at the execution test plan pages.
- testsuite custom fields that have to be defined when you are in test case specifications. You can display and modify only during test case specification. It will be display only on execute page in the test suite section if you have values.
- testcase custom fields that can be display and modifeid during execution on the test plan pages.

Also when you choose to set up custom fields you allow other combinations but they don't seem to work as expected.
ex. for test cases. - you can choose to display only. well this doesn't make any sense.
for testsuite - you can choose to display and modify on execute. but this doesn't do anything. you need to enable on test case and display on testcase for it to show up.

If you think this is worth anything we can open a ticket for this.

thanks
shirley

[fman]

Regarding:
-- Also the choice one have for the custom fields is kind of confusing we found -- that you can basically define the following things:

First: if some words seems not polite, i apologize, because is not my intention.

Right now and probably for a while we are not going to add some kind
of coherence control on Custom Field, options, because the workaround is
simple: read the documentation.
Anyway I will try to think if there is a simple way to improve the controls.

Regarding nonsense choices, again first cure is user have to do things in
the right way, not trying to push to the limit the config, only to see the outcome is not useful , i.e. better think config meaning before acting.

I will try to think how to allow bulk assignment of Custom Fields for TC during execution.

Test suites's Custom fields must be considered just as documentation
and I think will be not saved with results, because they are NOT TC custom fields

Feel free to open an issue, explain as much as possible what you
think can be useful, and think if you are able to help us to develop it


Regards

[shirlc]

Thanks for such a quick response. Do you have documentation out for 1.7 already that would help a lot? I didn't find anything in any of the obvious places. But it is not necessary for most things since a lot is very intuitive compared to many tools I've used in the past. I will post something in mantis for the bulk custom field for test cases on execution. I would love to contribute but only know perl unfortunately, haven't had the time to pick up PHP. Maybe in a few months after we get this all setup and defined for use for my team I will have some time to do such a thing.

Thanks again it is a wonderful tool

[fman]

You can contribute in several ways (not only developing)

1. testing
2. Creating documentation or simple how to's.

3. If possible add your company name in the forum section ( we will be happy to see the number increasing, right now count is 3)


regards

francisco