Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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 requested, with 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 ongoing process,therefore QA team in Korea always facing code is not updated, bug discovered this minute has already been resolved/debugged last minutes.
  2. Lack the 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.

share|improve this question
2  
This question is very generic, Please update if you face any specific challenges / Issues. –  Siva Jan 17 '12 at 8:47
    
Updated, hopefully it is clearer. Thanks –  JTang Jan 19 '12 at 6:33

4 Answers 4

up vote 0 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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