Join 34,000+ subscribers and receive articles from our
blog about software quality, testing, QA and security.

Is there a way of duplicating Test Plans?


#1

Hi!

I am trying to migrate our internal checklist into Test Rail. The preferred way would be to migrate it to an empty project and duplicate it when there is a need for a new one, but I’ve read that it’s impossible to do so. I am wondering if it’s at least possible to clone/ duplicate entire test plan?

I know that it’s possible to copy test cases between test suites but it’s highly impractical for me: I manage about 10 projects/ year. Each of them have 11 test Suites. They need to be arranged between 5 test plans that contains about 5 suites each. Copy pasting suite by suite and rearranging them into test plans would require hours of manual work. I can’t afford that.


#2

You can use the re-run option on a testrail test plan which will then allow you to select which cases to re-run and will add them to a new test plan within the same project.

Some questions on your scenario which might allow better suggestions:

You have 10 projects each having 11 test suites - are they the exact same 11 suites or can they be modified/different for each project? Any reason you can’t have a single massive “suite” with 11 sections and only include the appropriate sections for each project/plan?

Are the 10 projects all executed by the same group? It might be easier to have a single project and use plans and milestones to separate the project results if they all share a common set of tests. Your call but cases are copied across projects so updates don’t get synced back to equivalent cases in a different project.

Each project has 5 test plans with ~5 suites - does this mean each test plan has ~5 of the previous 11 suites attached to it? What differentiates each test plan within a project i.e. why not just one plan? If they are running the same tests in different configs the test plan configs might be a better way to split the testing.

Hopefully these questions/comments are helpful

Cheers

JG


#3

Hi!

Thanks for the fast reply. The 11 test suites are very generic and all “test cases” are actually of scenario Testing character. I thought about making one massive “suite”, but it’s impractical because current suites are based on different stages of the project (couple of them are Alpha, couple of other are Beta, couple of them should be done at every milestone etc. When I want to rerun “Alpha suites” I don’t want to touch suites from other milestones)

Your solution to create one single project is also difficult for several reasons. It comes with some drawbacks.

  1. Terminology confusion: “Project” for us is a new software done by different teams. This solution would indicate that all testing for all software is a “Project”.

  2. One of the most important reasons why I am investigating Test Rail is time estimation. If all testing is grouped as one single project I think the overview tab would display only one single graph. I would really need a graph/ project to keep track of trends among our own projects.

  3. If 10 different projects are labeled as “Test Plans” and have milestones of their own… How would that even work with Test Rails definition of “Milestone”?


#4

Hi Artur,

Thanks for your posting! We would usually recommend using as few test suites as possible and TestRail’s default mode for projects even just uses a single suite. We found that a single suite is much more flexible when it comes to creating test runs/plans and reports. Instead of using suites to group your cases into smaller units, you can just use an additional layer of sections in a single suite (or other means such as a custom field to tag your cases). You can flexibly include or exclude cases on the test plan form as you like (via select cases) but this also gives you the option of starting runs/plans for all cases or any subset thereof.

If you test against multiple versions at the same time, I can also recommend looking into TestRail’s single-suite mode plus the additional baseline mode which lets you create copies of the master repository (test suite) to track multiple versions in parallel:

https://blog.gurock.com/test-management-test-case-versioning/

Regarding time estimates: the overview charts on the project page or dashboard would show past activity rather than time estimates or projected completion dates. You can find the estimate on the test execution pages, e.g. for a test plan/run or a milestone and this looks as follows:

http://docs.gurock.com/testrail-userguide/userguide-tips#scheduling_and_forecasting

Using a single project is actually beneficial compared to multiple projects in this case as well. You can still create as many milestones/sub-milestones or test plans/runs as you like but can also group multiple related plans under the same milestone/sub-milestone (which gives you a combined estimate/progress/projected completion date).

I hope this helps!

Cheers,
Tobias


#5

Hi!

I don’t mean to be negative but I can still see a practical downside to single suite solution. We have 10 projects/ year and at least 5 stages of each project. In reality we have to make several reruns for each stage (typically 2-3 but 10 reruns are not unheard of). That would mean that at least 150 Test runs would be grouped together on a single page. Wouldn’t it be very hard to keep track of all test runs?

The time estimate function I am hoping for: Let’s say that a certain Test run took 100 hours. A rerun is scheduled for February. Therefore it’s quite likely that this project will require testing 100 hours from my team in February. If we have dates for test runs and reruns for multiple projects it should be possible to add them together and calculate the amount of estimated workload months in advance.

I was under the impression that this functionality exists in Test rail and could be seen in the Dashboard. Am I wrong?

I am also interested to see if one of the projects requires more testing time compared to other projects and be able to trace the reason for it to test sections and even test cases.


#6

Hi Artur,

Thanks for your reply. The number of runs would usually not differ between the two different suite modes. If anything, in our experience you would usually have less runs with the single suite mode as you can include all cases in a run or any subset thereof whereas with the multi-suite mode, you would usually create a run for each suite. That said, in both cases you can group multiple related test runs under a test plan and this would reduce the number of test runs on the overview page. Test plans

Regarding the estimates and progress: you can track the estimates, forecast and progress per run/plan or milestone on their Progress pages:

http://docs.gurock.com/testrail-userguide/userguide-tips#scheduling_and_forecasting

The Progress pages will always show the estimated time to complete the run/plan/milestone. Once you’ve started working on a run/plan/milestone, TestRail will also use the current velocity (how fast you are progressing) to calculate a projected completion date and forecast. This is based on the estimates as well as the historic test execution times (forecast/elapsed values).

Cheers,
Tobias