"Test plan -> build" db relationship

[Rab]

Hello

With me using testlink for over 2 months now I am starting to really get to understand it. Today I was trying to add new test plans and noticed something which I think is not quite right. I am sure there is a good reason for it, but from my POV as a former software & Db developer and now as test manager I cant understand the database relationship that has been setup for this.

I thought that a Test plan would have a set of Test cases associated with it. When you combined this with a Build you would get a set of results (e.g. Test plan A run against Build A = results for test cases 1 - 5). However, this doesn't seem to be the case.

If I add a new Test plan, I have to define builds for this test plan (I know I can copy existing builds when creating the test plan, but any new builds I add would have to be added individually to all my test plans). IMHO I think this is wrong; builds should be independent of the test plan and it is the combination of test plan (and its test cases) with a build that creates a unique set of results.

I also noticed that once a test case has been run in a test plan, there is no way to ever remove it. IMHO this is also a shortcoming - test plans should be able to evolve over time with new test cases being added and existing ones removed as required. I of course understand that I should not be able to remove test cases that have been run against an existing build, but if a new build is selected then I should be able to remove the test case.

If you would further info about what I mean, let me know and I could perhaps draw up a mock Db table relationship as I am suggesting. But basically I am saying that I dont think the "Test Plan" should be a parent of everything. Please feel free to tell me I am mistaken (as I am still a new user) if I have missed something or to explain why it was done this way.

Thanks
Rab

[fman]

Design choices have to be read with the context that have generated it, IMHO.
Then you can not said (again IMHO), this is BAD full stop without knowing origin/constraint that lead to the choice

Design choice of test link has been: Builds are owned by Test Plans.
We can said that it will be better if Builds will be owned by Test Projects, if you consider a Test Project related to a product/application (on TL version < 1.6
product term was used, and changed later to Test project). But effort to refactor is to high and value low (IMHO)

Test Plan + Build + each Platform (if any exists) set what I like to call 'Execution Context', where test plan provides the set of test cases to be executed.
Again in origins a design choice was done: Test Cases are linked to TEST PLAN, and after PLATFORM feature creation, Test Cases are linked to
(Test Plan + Platform) pairs.
On Firts implementation Test Execution TASK was assigned ONLY at Test Plan level.
People from Mobotix that contributed to TestLink development for a while, suggest the need of a feature that allow ignore test case present on test plan
for reports and metrics on different builds, to cope with regression an other needs.
Because design choices also have to consider impacts on previous installations, changing test case assignment to test plan to include also BUILD was considered not a good solution. (at least for Development Team, owner of TestLink efforts)
A different solution with lower impact was deviced to cope with this need: this was TASK EXECUTION assignment AT TEST PLAN+BUILD.
This way if you have test case TC1 on test plan, you have executed (or not) it on Build B1, and do not want it to create confusion on metrics regarding Build B2, is enough that YOU DO NOT ASSIGN EXEC TASK to any user on B2, and it will be ignored.
Same happens if you add NEW test cases to test plan AFTER B2, there are not going to create confusion (will be NOT RUN!!) on Build B1.

This is how things work, and there are no plans to change it in the future.
Hope now things are clear.

Best Regards
Francisco Mancardi
TestLink Team Leader

[Rab]

Francisco

Thanks for the reply. I absolutely know how these things happen, this happens at my company too where things could have been done differently but it is too late to change now and not worth it.

I had a good think about this last night and think I have a way around this; I will just need to make a new test plan at the end of each sprint and then include all the test cases that I want. I had originally thought of having a few test plans that I would re-use (e.g. full system, regression, performance etc.) for each sprint where necessary and change them slightly each time depending on the sprint content.

All I would say is that were you one day to refactor/redesign (i.e. major overhaul) then could I suggest you consider my idea

Thanks
Rab