分布式团队中沟通引起的问题, itest 解决之道

导读：

从问题场景和 itest 优雅解决办法及示例2部分来阐述

1.问题场景:

研发团队是分散在几地的分布式团队，常常会因沟通引来一些问题。以下三图是开发以为测试进度太慢，一番对话以后， 接下来他们的对话截屏：

 

 

 

   问题的本质其实是沟通的问题，多问几句也能够解决，可是经常是一人测试多个项目，开发也是一人参加多个项目，只要当前不闲着，加上又是分布式团队，可能有些须要沟通的事情，就先推后，不到最后要处理了才来沟通，在itest 开源测试管理中，从机制上根本避免了这个问题。

2.itest 优雅解决办法及示例:

      关于BUG指派不清的问题，ITEST 有两个保障，一：能够在测试流程中，由测试负责人（测试leader 之为的的测试人员）设置BUG分配人，提交的BUG先到分配人那里（分配人一般是某个项目的开发负责人），再由分配人（分配人能够设置多个）来分配到具体开人员；二：可对测试需求模块，设置开发人员，当提交的BUG时，指定了该模块，就自动设置修改人为以前设置的开发人员，若是是大团队项目，可能一个模块就量个子系统，还能够对测试需求模块设置分配人。

     ITEST中有上述两个保障后，测试执行人员，根本不须要关心，这BUG提给谁，只负责执行就行。

 

  以下图所示：

  设置测试流程并附流程设置说明：

 

  流程说明：

 

1 * 提交问题：必选流程，人员主要为测试人员，不是提交问题这流程节点上的人员也可填报BUG，只是不能确认BUG是否己修复。

2测试互验:可选流程，当测试人员和开发人员不在同一地点办公时，或想测试把关新手提交的BUG时，开启该流程，由资深测试人员来作测试互验，既能够指导新人编写高质量的BUG，也能够在开发人员在处理BUG前，测试人员内部先检查新提交的BUG，省去了可能的因BUG描述理解差别上，或是BUG可复现上带来的和研发人员的沟通成本。

3分析问题:可选流程，分析BUG产生的缘由，估算修复BUG须要的时间及期限，通常为研发经理，系统分析师来作分析工做。

4分配问题:可选流程，单元测试时，或团队规模比较小且测试人清晰的知道开发人员所负责的模块时，能够不启用该流程，测试人员提交的BUG，直接分配给开发人员。通常分配人应该为研发经理，研发组长等，能够有多个分配人。

5 * 修改问题:必选流程，顾名思义是修复BUG的环节，设置的人员是研发人员。

6开发互检:顾名思义是开发人员修改完BUG后，他们间的交叉检查。设置的人员是研发人员。

7 * 分歧仲裁：必选流程,当测试人员和研发人员对某个BUG的达不成共识时，或研发人员要求BUG延期修改，或不计划修复某个BUG时，由仲裁员来裁决。通常仲裁员为研发经理，或产品经理。

8 项目关注: 可选流程，设置项目关注人员，这些人员，在项目中不作具体的工做，设置为关注人后，这些人员能够在“切换测试项目中” 切换到所关注的项目

 

 

测试需求项（测试需求模块）人员分配：

 

 

itest 是一款: 汇聚10年沉淀，由对软件测试有情怀，热衷于开源，又热心传播分享的一群测试人共同打造，最懂测试人的开源测试管理新秀。

。也可在线体验，也有一键安装包，  https://itest.work/rsf/site/itest/product/index.html

后续咱们会陆续，把ITEST下面几个方面分享出来，欢迎拍砖：流程驱动测试，度量体现测试人价值，测试负责人每日复盘，敏捷测试，迭代测试，devops 下如可组织和管控测试等，