Shared project and distributed testing
I am looking for some general suggestions or pointers to some good articles or videos that cover the best way to manage a project that is shared by 4 people and also used in distributed testing. ...
Forum Discussion
Hi Mark,
While it is usually OK to execute tests on different machines using the same project opened in a networked mode (exactly like you do), I would strongly recommend not to use concurrent development.
According to my experience (and the topic recommended by Tanya basically says the same), the best way to organize the development is like this (general principle - only one person is responsible for the given project item):
a) Consider creation of the common reusable code and move this code into one or more script units. Assign a dedicated person (usually - the most experienced TestComplete user) who will implement code changes into this reusable library. There may be more than one such dedicated person if your project contains more than one library code unit, but in this case they must have their own library code units assigned;
b) This dedicated person is also responsible for making changes in the NameMapping by requests from other team members. Also this person is responsible for integration of all tests created by other team members and for verification that integrated tests still work and do not interfere with one another. Also, during tests integration, this person should analyse test code and move reusable parts into common library;
c) All other team members should use their own local copies of the test project and modify only module(s) they are responsible for. After the developer test code is provided to the person mentioned in paragraphs a) and b), the given test member should synchronize his local copy with the master one from the network.
Summarizing: every team member changes only the code module(s) he is responsible for and do this on his local copy. All code merging, like the changes required to be done for other project items (e.g. changes in the NameMapping, changes to the test items, project variables, etc.) must be done manually by the dedicated person. Then the changed project should be delivered back to the machines of team members.
While it is usually OK to execute tests on different machines using the same project opened in a networked mode (exactly like you do), I would strongly recommend not to use concurrent development.
According to my experience (and the topic recommended by Tanya basically says the same), the best way to organize the development is like this (general principle - only one person is responsible for the given project item):
a) Consider creation of the common reusable code and move this code into one or more script units. Assign a dedicated person (usually - the most experienced TestComplete user) who will implement code changes into this reusable library. There may be more than one such dedicated person if your project contains more than one library code unit, but in this case they must have their own library code units assigned;
b) This dedicated person is also responsible for making changes in the NameMapping by requests from other team members. Also this person is responsible for integration of all tests created by other team members and for verification that integrated tests still work and do not interfere with one another. Also, during tests integration, this person should analyse test code and move reusable parts into common library;
c) All other team members should use their own local copies of the test project and modify only module(s) they are responsible for. After the developer test code is provided to the person mentioned in paragraphs a) and b), the given test member should synchronize his local copy with the master one from the network.
Summarizing: every team member changes only the code module(s) he is responsible for and do this on his local copy. All code merging, like the changes required to be done for other project items (e.g. changes in the NameMapping, changes to the test items, project variables, etc.) must be done manually by the dedicated person. Then the changed project should be delivered back to the machines of team members.
