Forum Discussion

kso's avatar
Occasional Contributor
15 years ago

Projects/Script Organization best practices


I wonder if there is any best practice for the organization of projectsuites/projects/script

that take into account versionning of tested solution.

We have several solutions with different release supported that run on different environment.

For each version of a solution, script may evoluate, be deleted or created to test a new functionality.

So what is the "best " organization to manage the different script for the different version of the different solution.


4 Replies

  • kso's avatar
    Occasional Contributor

    Why couldn't we add a ProjectSuite into another ProjectSuite or Project ???

    Why couldn't we create group of test Item on a ProjectSuite ?

    I have a global Product P which has 4 specifics Sub-Solution Pa, Pb Pc, Pd

    Pa, Pb, Pc and Pd share many features ( same binaries, same install procedure (which contains 4 steps (exe setup) ...)

    To simulate Pa, Pb ... I use a directory DirPa, DirPb ..

    and add under each  directory,  projects to test functionnalities f1, f2 (Paf1, Paf2 ...)


    |-Dir Pa

    |     |- Paf1, Paf2...

    |-Dir Pb

    |     |- Pbf1, Pbf2...



    |     |- PInst1, PInst2, Pinst3, Pinst4


    |     |- PCom1, PCom2...

    But now, if i want to test all the functionalities of product A, i cannot create "test item" on the folder DirPa

    which simulate a projectSuite.

    I would like to create group of test item on the highest level P in order to group all the item of the sub-group Pa.

    But we cannot create Group on a projectSuite....

    So how can we do:

      Create one ProjectSuite, with 4 Projects (Pa, Pb, Pc, Pd) and create all the functionnal scripts under each project  ???

       back to my question on versionning, if i want to test  the version V2 of product A and support tes regression of the V1.2 and V1.0 

       I have to create project Pa_V1.0 with all scripts, Pa_V1.1 with all scripts(modified, new ones and deleted ones) an Pa_V2.0 with all scripts(modified, new ones and deleted ones)

    So what do AutomatedQA  consider a good approach ?

    How do we have to manage our projectsuite/project to support multiple products sharing elements and supporting versionning ?


  • Hi Karim,

    Test organization in TestComplete has three main levels: project suite, project and test item. You can have several projects and combine them in several project suites, and you can have common tests (scripts or keyword tests) shared among different projects. Please find more information on this ability in the 'Sharing Project Items and Their Child Elements Among Several Projects' help topic ( This topic describes how to share a project item among different projects, but you can use the same approach to share a project among several project suites.

    As for the versioning of tests, there is no built-in feature to do this. You can implement this by creating copies of the existing tests or, probably, using this functionality of a source code control system if you use such a system.

  • kso's avatar
    Occasional Contributor
    Thank You David for your response,

    My problem is that we have a product P which is made up of 4 specific solutions S1,S2, S3,S4 which in turn share severel things (binaries, install procedures).

    So, i naturally created 1 ProjectSuite for the global product P, define variables shared by all solution Sn

    I have created sub-directories  S1, S2 ... to simulate the solution under which i create a project for each functionnalities i have to test.

    I have created a project Install and a project Common, under ProjectSuite P, that can be shared between all the projects

    by referencing the scripts (Since they are in the same ProjectSuite).

    If i want to test a specific solution, i check from the project suite , the project Install and all the project under directory S1

    =>I would have like to be able to create a group of test item on the ProjectSuite in order to group all the functionalities of a solution (install and all projects under the directory Sn) so that I would be able to test each solution without to check/uncheck project from the ProjectSuite

    Now, if i create a ProjectSuite per Solution, how do i share information between ProjectSuite ??

    -> i have to duplicate variables  , clone projects (by example project Install, and Common) since we can't share/reference script from one ProjectSuite to another.  -> for me , it's a bad thing

    If i had to make a correction, i will have to report the changes in all the copies (so at least 3 copies)..... -> Bad things ...

    If i  create a ProjectSuite Install, i have to externalize the logic out from testComplete to run the Install test and the Acceptance test of the solution.

    The last solution is to create 1 project per solution, and have a script for each functionnality tested. In that case, i will have many

    files, regiosn , tables  under Stores and it will quickly be unmanageable.

    It seems to me that If i would be able to insert a ProjectSuite under another ProjectSuite , it will solve a large part of the problem.


      karim SOUAK



  • Hi Karim,

    It seems that you need something like project suite configurations. I have registered your request in our database, thank you.

    The best solution I can suggest is using several project suites. Please note that you share the same project among several suites. So, you can add your Install and Common projects to all your project suites.

    However, this does not solve the problem with project suite variables. To workaround this restriction, you can store the needed values in a separate storage file (e.g. a CSV or Excel file) and load information from this file to project suite variables at the beginning of your tests. For example, you can set the Common project to be the first project in all your project suites and the only test item in this project will read the needed data from external storage.

    Please let me know if you need help in working with CSV or Excel files.