分布式团队中沟通引发的问题, 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 下如可组织和管控测试等，