Thanks a lot to the testlink community for developing and maintaining this very useful tool!
We are using testlink in a project with frequent releases/builds, some of them with minor changes that require minor testing in specific areas, some of them with big changes that require full regression testing. We are using testplans to group tests into small groups, and for each release/build we select which small groups of tests to run:
build 1.0: "QA, please run test plans A, B, C"
build 1.0.1: "QA, this time you just need to run test plan C "
...
However it seems that this is not the scenario that testlink developers had in mind, because builds are specific to each test plan, not to test project. So to do the above, we would need to re-create each build in all the testplans. Can someone suggest a way that is more aligned with the testlink way of doing things?
1. one test plan(considering as major release) and 'n' no. of builds till we achieve the target
2. One test plan(considering as normal) and it contains only one build.
This is up to the end user to use it.
To me Build will always be tied up with test plan which makes sense
Thanks a lot for your answer. If I understand correctly, did you mean that the expected way is to have a testplan for each kind of build?
E.g. one testplan for builds that change many things, one testplan for builds that change something here, another testplan for builds that change something there, etc, and then for each build we just select the most appropriate testplan?
I guess this will do the trick but at the cost of having many overlapping testplans, e.g.
testplan1 covers modules A, B,C
tesplan2 covers modules A
tesplan3 covers modules A, B
tesplan4 covers modules A, C
...
Thanks a lot for your answer. If I understand correctly, did you mean that the expected way is to have a testplan for each kind of build?
ANS : As said earlier it is up to the end user how hhe wants to use, this actually deoends on the way of reports they generate creating a test plan with one build or multiple test plan with multiple builds is not only matter, you also need to understand from reports perspective that you were trying to generate and set the process to your needs.
E.g. one testplan for builds that change many things, one testplan for builds that change something here, another testplan for builds that change something there, etc, and then for each build we just select the most appropriate testplan?
I guess this will do the trick but at the cost of having many overlapping testplans, e.g.
testplan1 covers modules A, B,C
tesplan2 covers modules A
tesplan3 covers modules A, B
tesplan4 covers modules A, C
...
Was my understanding correct?
ANS : I will explain you more detail, you can use test plan as major release and contain more builds in it or for a single build you create a single test plan, that is all how you customize as said earlier it is up to end user on how comfortable in using and tuning the process
"