Sometimes, when managing testing activities, two levels of hierarchy - test plans and their child test cases - is not enough to organize your tests. Starting in version 3.5.0, you can organize test cases into hierarchical test plans; this means that you’ll have the ability to include a test plan into a higher level test plan, which themselves can be a part of an even higher level test plan, and have test cases reside at the lowest level.
Why do we need it?
Now you can organize test cases in a test plan into groups (lower level test plans) based on many different parameters, such as - only to name a few - different types of testing (smoke and regression tests, for example), test case priority to specify which groups need to be executed first and which last, or by user story (thus creating a user story test plan) to see which user story every single test belongs to during execution. Having the capability of linking existing test plans, you can now create a new test plan for every single iteration, release, or feature, for example, and link your existing test plans to them. This allows you to execute test plans multiple times in different releases, iterations, or features and see the run results. There are many different approaches as to how you can use it.
Where to start
Let’s take a closer look. To create a hierarchical test plan, you can either add a new test plan to another plan at any level using the quick add button or select an already existing test plan using the lookup on a test plan view. In a similar fashion, you can create new test cases or link existing ones.
To unlink or delete a test case ot a test plan right click to use the context menu:
When a hierarchical test plan is ready to be executed, we create a test plan run and see the same structure within it. This allows to stay focused on the right child test plan run during its execution.
Every child test plan run can be assigned to people, which allows to break a test plan run execution into several parts and assign each portion to different people. Here, in the same list, you can also close a child test plan run if the execution is completed. Having this view allows you to see what groups of tests have already been executed and which are still in progress.
Having test plans selected as lanes, you can see child test cases and plans selected as cards.
When you have test plans shown as cards or lanes on a view and you don’t want to see any child test plans, you can use a filter ‘?ParentTestPlan.Count == 0’ to hide them.
We’ve also updated the Last Run Result unit which you may use to be shown on cards to see the results. Now, it shows the results of the last test plan run related to a test plan, not the last run results of every test case inside a test plan. This allows you to reuse existing test cases and plans instead of copying them every time you need to execute them and still have the appropriate information shown as its result.
Check the following video to get more information on how to use this new QA area in Targetprocess 3:
We believe these changes will allow you to organize your test cases and test plans in a better way. Let us know what you think. Your feedback is much appreciated!