Test Case Reuse

Reusable test cases that can be used across different projects can be a difficult to implement and manage. There are some good ways to approach this though. In this article we look at ways to configure your test management tool so that you can effectively handle main products and sub products effectively.

As a practical example we’re going to base this on a submarine. Where we’re looking at managing the major release of the submarine, and independently managing the Engine, Periscope and Radar sub products. We’ll look at working separately on these engine, periscope and radar products. Then rolling up work on those to include them in a major release of the submarine.

You can see an example of this in practice with QAComplete in this video

So the first concept to grasp is the structure of the releases. We’ll have many releases of both the main and sub-products. So our approach can be modelled with the following structure.


Submarine Major Release
Submarine Release 1.0
Submarine Release 2.0

Radar Sub Release
Radar Release 1.0
Radar Release 2.0


What we’re trying to achieve here is the concept of testing individual components like the engine, periscope and radar. Each of those sub-products will be tested and released in it’s own right (independently of each other). Then at some point those sub-products will go together to make up the major release of the submarine. We’ll need to check those components as part of the submarine release reusing testcases from the individual sub-products and new testcases for the major submarine release (e.g. integration that shows the components working together).

Next we need to write cases for each sub-product. With QAComplete/ALMComplete we have the concept of a library and a set. Where the library contains a range of reusable testcases (possibly broken down by functional area). These library testcases are grouped and included in a set. Where the set is then run against a particular release. So the structure of the testcases might look like this.


Engine Test cases
tc-e1
tc-e2
tc-e3

etc


The whole point of this is that we have grouped our testcases logically into groups (or sets) that represent both the sub project they relate to (e.g. the engine) and the types they contain (e.g. regression or performance).

Now the clever bit is that those sets can be linked back to multiple releases. So we can run each set multiple times against different releases. So we might have.


Engine Sub Release
Engine Release 1.0
ts-e1 executed against release 1.0
ts-e2 executed against release 1.0
Engine Release 2.0
ts-e2 executed against release 2.0


The key within QAComplete is that when you link sets to releases like this you can select a release for a sub-product and see exactly which testcases (within a set) have been executed.

Furthermore with this setup we have a good framework when it comes to re-running tests against the main submarine release. We can link sets we’ve already developed for the sub-products quickly and easily to the major submarine release to reuse our tests to give us regression and integration coverage.


Submarine Major Release 1.0
Engine ts-e1: Regression (containing tc-e1, tc-e2)
Engine ts-e2: Performance (containing tc-e3)
Periscope ts-p1: Regression (containing tc-p1, tc-p2)
Periscope ts-p2: Performance (contianing tc-p3)


The importance of this approach should not be overlooked. It’s the ability to use different sets and link them to many releases (major or minor). Each link giving us a different execution run and a different set of results. And with this the ability to quickly and easily reuse testcases for our major release. Not only this but we now have the ability to track and report both at the major and minor component/project level.

A well thought out structure like this, that maps well to the test management tool in use, can have big benefits when managing your projects.