Your ability to manage a library of testcases in your test management tool depends a lot on the relationship between the different instances of the testcases. The instances that resides in the library and the instances that are created to be executed and run. At a basic level you you will have two instances of a testcase..
1. The instance that resides in the library. This is the master copy of the testcase and will not usually have a result record associated with it.
2. The instances that have been used at run/execution time. These instances will all have a result (pass, fail, not yet run, etc) value against them. They may differ from the instance that resides in the library or they may be identical.
It’s the relationship between the library and run time instances that complicates our test management process. If a testcase was only written once, never updated and was identical each time you ran it then things would be very simple.
However, testcases evolve over time. Each time they are executed there may be subtle or major differences. You end up with different versions of the testcase in the library and different versions being run against different releases of the product being tested. At the core this is all about how different instances of the same testcase are linked and updated. We need to have:
The concept within the test management tool QAComplete (as shown in the video above) is that you manage different versions of a testcase within a library. When you come to run this within a ‘set’ a copy of the testcase is taken for us to record a result against. This means that you have two independent case entities. Both can be updated independently of the other. After creating the run instance of the testcase you can:
a. update the library instance without affecting the run instance (important because the result is recorded against the run instance and once recorded you don’t want changes to be made to the test case as they may invalidate the result)
b. update the run instance without affecting the library instance (you may want to make changes to the steps just for this specific run but these changes shouldn’t be applied to future runs).
c. update the run instance AND propagate that change back to the library so that it incorporated in future runs (this is useful because frequently when we run a test case we realise that we haven’t written it quite right and a few changes are needed).
QAComplete does not support the following library test management concepts:
d. Updating the library instance AND propagating that change to the instances already assigned for execution (usually not something you’d want to do as it would invalidate results already completed, but it can be useful in some instances).
e. Replicating updates across projects where different projects are using the same case.
It’s the capability to isolate yet link testcases between the library and run instances that gives a QA team the ability to manage their cases effectively. It’s important because if your test management tools doesn’t support these concepts you’re in danger of having invalid results and having the onerous task of managing all these different instances of the same testcase manually. If you end up doing that you’ve lost one of the key reasons for having a test management tool in the first place.
