How to managed test cases across releases

[renjithgm]

Hi , We recently started using testlink . Can some one advice on how to work on the below scenario.

We have various test suites and we have completed test execution for one release cycle . Now in the new release some of the test cases will get obsolete or edited due to the feature / product changes .
Latter on we will also need to execute test cases for both releases. How can we achive this by not duplicating test cases ? Can we tag test cases against releases ? Keyword are already overloaded.

Thanks In Advance
--Renjith-

[Amaradana]

you can inactive the obselete test cases in this way when you try to add test plan, you can not see the inactivated test cases

and for the test cases that you edited, change the version and assign the changed version of test cases to test plan.

if you already assigned test case to test plan and you want to updat ethe changed version for that test plan, you eed click update test case linked version, in this way the test case will be updated.

[renjithgm]

Thanks a lot of the response .
My question was more to figure out how I can manage test cases for various version of a product ,
say once we complete a release of a Version (V1)of the product, then Baseline all the active test cases and tag with a flag called V1.
Now for the next release we will continue to work ( modify /edit ) the test cases . At any point you want to execute old test case search for a the flag V1 you get all of then and create a test plan with those test cases and execute them . like this create retrievable versions( taged) of test cases .

[Amaradana]

IMHO, This is not a good practice, Why do some one want to re-xecute the old version of test cases?

I suggest you to understand the process of your company before you start testlink.

VERSION : Version of test case will only change if any change in the requirement/specification. if version changes your older version will be obselete, if there is a change then why do you want to re-execute the obselete version?

[renjithgm]

Need to Run Old testcases :- Old test case are how the a feature behaved in the previous release . We have a requirement to test newer devices with older releases

[kob]

IMHO, This is not a good practice, Why do some one want to re-xecute the old version of test cases?

I suggest you to understand the process of your company before you start testlink.

VERSION : Version of test case will only change if any change in the requirement/specification. if version changes your older version will be obselete, if there is a change then why do you want to re-execute the obselete version?

Why not, maintanence releases will not have the new features so you will need to run the old testcases.

Need to Run Old testcases :- Old test case are how the a feature behaved in the previous release . We have a requirement to test newer devices with older releases

What you will need to do is to create a new testplan for your new release. As long as you don't update the old testplan, it will have a link to the old versions of the testcases.

[Amaradana]

@ renjithgm
you can run as you did previously.

@Kob
Version is different from the word test cases.

Say your test case version is 2 which is as per the latest requirement. there is no point in executing version 1 as it is obselete. I hope you can understand what i mean.

[drutt]

Say your test case version is 2 which is as per the latest requirement. there is no point in executing version 1 as it is obselete. I hope you can understand what i mean.

Not necessarily.

Say you have two versions of your product, V1 and V2. Each version is released and used by a number of customers. After doing maintenance work (bug fixes) on V1, you need to do regression testing using the test cases valid for V1. You can't use the latest version, because those test cases are not valid for V1.

I'm facing the same problem and looking for a good solution. I guess the solution would be to create multiple instances of the same test case and assign each instance a specific keyword such as "V1" and "V2". Then you can filter out test cases and create your test plan pointing at the right variant of each case.

If anyone has a better solution, I would be glad to know.

[Amaradana]

different versions great,
So both test case is different in v1 and v2 of your product.

then maintain two sets of test cases which solves your problem

again version is different from the word test case, from the above i see that its product version but not the test case version, do not mix up the test case version to the product version

[kob]

Seems I didn't get the point before ...

Still I link a test case version to the product version ... I don't see a need to create a new test case, but I guess that depends on how you work or like to work.
For me it's like using version control in software development. The same test case evolves together with the software and it will have different versions linked to the software/product version.
So if there is a maintenance release on an older version, you will execute the older version of the test case.

Only thing I'm missing is a decent Test management system to manage this properly. So far Testlink fits best my needs.
What I would like to have is that the test case management is put outside the project, and allows you to have multiple versions of the same test case and to make branches and so on ...
But that's an other story ...

[Amaradana]

Still I link a test case version to the product version ... I don't see a need to create a new test case, but I guess that depends on how you work or like to work.

IMHO, this is not a good practice. test case version change only when functionality or requirement changes. not with the product version. test case version is nothing to do with the Product version.

I don't see a need to create a new test case, but I guess that depends on how you work or like to work.

Agree i just gave you an alternate in managing. after all it all depends on how you manage the things

[rackam]

To complete this Thread, I would say that the way you manage Tests depends of the kind of Software you are working on.

Basically, WebApps have one single deployment, using dev, test, integration and Production Workareas. In this case, Tests Life cycle can quite easily follow the Application life cycle, as when a functionnality is modified, it is forever.

But some Software Company (still) have Business Models that rely as much on the sale of new licences than on long terms maintenance contracts. The Test or Qa Team would like to be able to use the same set of Tests for the v2 sold in 2007 but still covered by contract, for the v3 of 2009,..., in parallel.
One Team facing a "multi-releases Plan"..Doesn't smell like Agile...

For this case, I would suggest to duplicate the entire Test Project for each new major version of Products. It allows to simultaneously do some heavy work on TCases for the next Release, corresponding to new devs or major impacts from code refactoring, and being also able to run some kind of much shorter cycles of non regression Tests campaigns, for the periodic re-releases (eg Patches) of the "old" Product versions, all in the same time.
With Test Hierachies sealed in disctinct Test Projects, TCases of the "old" Product versions are preserved from the impacts of the work done in TCases for upper Releases.

I chose this way to do because it has seemed to me simplest than managing this by Keyword linkage or by Test Plan Assignment, but it is surely not the only one, nor the best. The worst for me would have been to duplicate branchs of TCases as Product versions in the same Test Project, for performance issues of having all Tests x all Releases in the same Hierachy.
Main disadvantage seems to be unable to have cumulative Reports, compiling data of more than one Major Product Version. Note that it does not prevent you to generate those Reports and to do some comparative or cumulative analyses aside.

Just be careful of not reaching PHP timeout when duplicating Test Project, unless, you will loose some data.

Nice if it could help !