Promoting Test Cases as Test Suites and Test Scripts as Test Cases

 Hi Amit,

Amit -

One thing to note is that a test script is merely the implementation of a test case and alternate test scripts are just implementations that validate the same requirements as the test case (perhaps in different test environments).  So the idea of promoting a test script to a test case doesn't really make any sense.  It could be that the test flow in the different test scripts deviate enough so that over time different requirements or flows are being tested but in general, that would suggest that different requirements are being validated and need to be reported separately requiring separate test cases.  In this case a copy and modify of the test case and attaching each test script to its own parent test case is appropriate so you can map to the different requirements.

Now growing test cases into test suites is a common occurrence as test cases tend to grow in length and richness of requirement coverage.  When it gets too big (and take too long to execute or needing more granular reporting), splitting it into multiple test cases using either copy test case and delete steps in multiple test cases while also splitting up the test scripts to match or copy into a test suite description section and then building the multiple test cases.  The work is still in the details of migrating covered requirement links to the appropriate test cases and divided up test scripts.

Although tool automation of some of these operations could speed things up, the actual work of migrating coverage links and matching up the test case and test script fragments are a lot of manual work.  I think that with copy artifact and cut/paste operations this should be fairly efficient as you scrutinize the test case and test script boundaries and reassess your requirement links.

These are just some thoughts about test assets that are already fully written and just need to be adjusted over time.  If on the other hand you have hundreds of test scripts that have no test case or requirement coverage mapping and you need to create all that, there is a huge pile of work to get everything into the normal RQM model.  Using the recent test case/script combined entry form may save a great deal of time in this case.

Hopefully this discussion is helpful to some degree even though no tool automation help is being suggested.