Forum Discussion

TestQA1's avatar
TestQA1
Frequent Contributor
2 years ago
Solved

Project suite size in Test Complete

Hi folks,

 

I need to know what's the best practice for using the Project suite like what's the limit for adding projects and how to know where to stop adding more projects in a suite and create a new one?

 

Thankyou!

  • My personal suggestion would be to have a separate project for every application you are testing. The project suite would act as your organization's/team's parent project and would primarily contain shared global settings and/or variables between the child projects. The individual projects should ideally have their own mappings, variables, bindings, executions plans, event handlers, etc. Really, I think it's just a matter of manageability, the nature of what you are testing, and what makes the most sense for your company.

     

    However, if you are hitting double-digits in your projects it might be worth considering breaking them out into different project suites or to just identify if there are any major commonalities or difference between the projects (design, events, framework, tested apps, etc.) that would justify combining or breaking things up - and this would primarily depend on the needs and capacity of your organization/team. 

1 Reply

  • Kitt's avatar
    Kitt
    Regular Contributor

    My personal suggestion would be to have a separate project for every application you are testing. The project suite would act as your organization's/team's parent project and would primarily contain shared global settings and/or variables between the child projects. The individual projects should ideally have their own mappings, variables, bindings, executions plans, event handlers, etc. Really, I think it's just a matter of manageability, the nature of what you are testing, and what makes the most sense for your company.

     

    However, if you are hitting double-digits in your projects it might be worth considering breaking them out into different project suites or to just identify if there are any major commonalities or difference between the projects (design, events, framework, tested apps, etc.) that would justify combining or breaking things up - and this would primarily depend on the needs and capacity of your organization/team.