Hello,
I am currently looking into TestLink to see if it could work for managing testing.
I am trying to understand and how best to enter my test cases and build my test plans in TestLink
I am struggling as I have many test cases which are utilized across multiple configurations (lets say operating systems), which all have the same instructions. I do not want to have multiple entries of these test case as it has been a logistical nightmare to ensure they are all updated when a change or correction is needed. My preference would be to have a single test case for this test and be able list it multple times in the test plan for different configurations. Is there a method to do this? I have searched around the forums here and read a lot of documentation that came with TestLink but I guess I don't see a method of doing this. (other then defining the config in my test plan, but then to actually assign one test plan to my tester, I have to assign to them in lots of little parts).
On top of this, These same test cases are used in multiple test plans. This prevents me from defining my configs by using Test Plan's.
Am I missing a feature or usage in TestLink?
So far I wish there was one more level in between the test cases and the test plan. A way of maybe grouping test cases (ie in my example based off operating system) which then can be grouped again into a test plan. This test plan then can be assigned to a tester. Thus my database only has to have one test case I need to maintain and keep up to date.
thanks,
chris
Managing Test Cases in Test Link
Moderators: Amaradana, TurboPT, TL Developers
You care it correct. You and also some other users complains to have "platform" field for test execution in addition. It's not implemented yet.
The reason is obvious ... it is difficult. TL must care about TC versions for particular tests, custom fields, builds, etc. Such implementation breaks this already difficult relations and add another level to all TPlan SQL queries.
I personally expect that way could be additional functionality for some specific settings. So the current functionality will not be broken. But nobody draft design for it yet. You can check tracker ...
The reason is obvious ... it is difficult. TL must care about TC versions for particular tests, custom fields, builds, etc. Such implementation breaks this already difficult relations and add another level to all TPlan SQL queries.
I personally expect that way could be additional functionality for some specific settings. So the current functionality will not be broken. But nobody draft design for it yet. You can check tracker ...