Sharing project artifacts across different projects within a test management tool tends to be difficult. For example, you create a project space within your tool of choice, develop lots of test cases and run them. However, you have another project running concurrently and they want to use the same test cases within a separate project space. Try to use the same test cases or artifacts across different projects and typically you end up copying the artifacts to the other projects. The big problem with this approach is that you then have two instances of the same artifact. Update one in one project and the other is no longer a direct copy.
Few tools seem to cater for these scenarios very well. Yet it’s quite a common thing to want to do. Companies develop many products, often in parallel and they all have say 90% of their features in common. Then possibly the another 10% of the features are unique to each product. So in this setup you’re likely to have requirements, tests and defects that are common across projects.
So a typical setup would be:
1 – define all the requirements across all of the products
2 – define all the test cases across all our products
3 – associate requirements which are covered by test cases
4 – Define the product to test
5 – Assign the relevant requirements to the product
5 – A project is created that indicates which test cases are required to cover all requirements for that product
This is quite a common setup. Yet most QA software products are structured around one project and versions of that project. If you create a new project/product, you have to import all the requirements and testcases from the previous product. And then you end up having to link all the requirements to testcases again (which is error prone). Then if you add a new feature that’s common across the entire product line you have a tedious process of copying and pasting, or importing, into every project.
It’s important to understand if you’re likely to encounter this type of scenario when testing your products. If so you need to consider approaches to managing this and find out how well the test management tools deal with this. We suggest one approach in our Test Case Retest blog post that can be used in QAComplete. It’s quite possible this same approach will work for other test management solutions too.
