4

I would like to seek for your valued opinions.

How do you get global teams (such as US, China, Korea, Singapore, Europe and Australia) which work on and are responsible for different parts of the system to test smoothly without latency, code conflicts and other issues?

As per request, with a specific example:

AUS is handling UI, CN is handling core design, each location has their own standard to perform unit & integrated test and maintaining their own servers. The problem now, QA team in Korea is testing on both integration(UI+core) at their local server, they found

  1. Since unit & integrated tests in Australia & China are in an ongoing process, therefore QA team in Korea always facing code is not updated, a bug discovered this minute has already been resolved/debugged last minutes.
  2. Lack of documentation(system requirements) of correspondents.
  3. How to ensure different parts are working fine before integration?

Thanks to famousgarkin for his time to edit my previous post.

Improve this question
1
  • 2
    This question is very generic, Please update if you face any specific challenges / Issues.
    – Siva
    Jan 17, 2012 at 8:47

5 Answers 5

Reset to default
0

The way I understood your question and keeping in mind my stint in an organization where the workforce was distributed across locations, I would suggest:

->Process is your friend As there is CI going on in Aus and China , a period of codefreeze should be applied.(thou shall not commit to the trunk) During this window when the codefreeze is ON , the Korean team can pick the build and look at the release notes (this can be auto -generated, Name of build , Bugs resolved etc)and go ahead with their testing on that build.) All the suitable tasks/bugs can be moved to a resolved state and tagged with the Build name in your Issue/Target/Process Management tool.

Meanwhile the Aus and China could look into work items/features aimed for the next build and the bugs unresolved so far .

At a suitable time depending either on the timezone conveniences or/and timelines agreed between the points of contact ( eg ..QA think they have sufficiently QAed the Application under Test) ,the CodeFreeze can be switched OFF.

Once the CodeFreeze is OFF, the Aus and China team can go ahead with committing their code to the trunk. Meanwhile the QA team in Korea can perform test prep activities in anticipation of the forthcoming build.

Basically this cycle can be tweaked, customized according to the needs/priorities of the project i.e the Codefreeze can be a dynamic activity where timely communication is vital.

Improve this answer
1

This is a big subject, too big to be satisfactorily answered in an Internet forum.

Of course this is relevant to testing, but it is not specific to testing. In fact, aspects of this problem are not specific to global teams. Any time you ask geographically dispersed teams to work together -- whether they are across town or across the ocean -- you will face challenges.

I am not an expert on managing global teams, but I have some experience working in geographically dispersed teams. The one thing I have seen make a big difference is allowing the teams to meet each other in person. We are social animals, and there is no better first step for gaining someone's trust and good will than to interact with them face to face. Of course this is not always possible. Sometimes the best you can do is to send a few emissaries, but even that is better than having no contact at all.

Improve this answer
0

We are facing the same problems, the way we do it is- Test domains are clearly defined in advance, if possible there is some overlapping between domains. Some of the domains cover the same functionality but from a different point of view. There's a single point of contact to collect summarized results, this POC has enough knowledge so he can judge the quality of the results, and can track that correct software releases were tested.

Improve this answer
0

According to the management of some open source softwares, you can do like this:

  • By using technology like Git, the chief architect and his team will have chance to easily review and test any of the code changes before merge them into the project. Also, the managers of the branch teams should review before his team member send the change to the main project.

  • Each code change should have a corresponding ticket in a issue tracking system. Developers and testers have different roles/groups in the system, and a workflow like On Working -> On Reviewing -> On Testing should be followed.

  • Only one team of the testers are running the integrating test. They only update from the main project. The other test teams will be responsible to ensure the code change works with the formal main project before the developers send the change to the main project.

Improve this answer
0

A case study on support of a global, functionally distributed development team focuses on the use of a container based environment (each developer working on an isolated sandbox) on a single shared AWS VM is available at: Windocks.com

The setup uses Git for centralized code repo, and a replicated SQL Server database which containerized and shared.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.