正交缺陷分类（ODC）流程简介及应用

校验小组成员间如何更有效的沟通？

校验小组成员通常会从测试和开发人员中分别挑选。在很多大项目中，测试和开发团队可能并不在一个地区，甚至存在时差。如何增强跨地区小组成员的交流，使得资源共享、沟通及时无误呢？这就需要有一个信息共享平台。从我们的实际经验中来看，wiki 是一个不错的选择。wiki 是一种多人协作的写作工具，每个人都可以在上面发表意见。下面是作者正在参与的一个项目组所采用的 ODC 校验小组 wiki 上的内容，包括如下方面。

• 目的：明确校验工作的目的；
• 校验小组人员名单：包括姓名和联系方式；
• 校验流程说明：针对本项目的特点，制定出适合本项目的校验流程。以作者参与的项目为例，校验流程可以包括：
  • 每周一，由 ODC 校验小组负责人分配给每个人这周需要校验的缺陷（分配的方式，会在下面的“每周工作安排”中提到）；
  • 校验小组中的每位成员开始逐一校验分配给自己的缺陷。如果发现该缺陷的 ODC 属性有填写不正确的或忘记填的，就需要马上发邮件给该缺陷的发现者或解决者，予以修改。若缺陷本身的描述信息足以令校验员分析出正确的选项，那么在邮件中需要写明校验员的修改意见及原因。若缺陷的描述信息不清晰以至于校验员无法作出准确判断的，也需要在邮件中指明。待测试或开发人员在缺陷中补充了更详细的信息，校验员再重新进行校验。
  • 一旦校验完成，校验员需要在缺陷管理工具中对该缺陷进行标识，如前面我们提到的“ODC 是否已被校验”属性项，这时把它的值从默认值“否”修改为“是”。以表明该缺陷已被校验过。校验组长下次再分配待校验的缺陷时，就会把已被校验过的缺陷过滤掉。
  • 校验员把在校验过程中发现的问题，例如错误分类趋势等进行反馈；
• 每周工作安排：
  • 可由如下表格进行工作分配和进展跟踪。其中的前两列由 ODC 校验小组负责人在分配工作时填写。后两列由 ODC 校验员在进行校验工作时填写。表 1 列出了一些可能出现的情况。

表 1. ODC 校验工作分配 / 跟踪表

表中的第三列“是否已被校验”与缺陷管理工具中的“ODC 是否已被校验”属性项相对应，同样有四个选项可供选择：不填表示校验人员还没有开始对该缺陷进行校验；“是”表示该缺陷已经被校验完成，可以作为评估阶段的统计数据；“否”表示该缺陷还处在校验过程中，等待相关人员根据检验员指出的修改意见在缺陷管理工具中进行修改。在校验员发出第一封邮件后的三天之内，若没有得到相关人员的响应，校验员需要发送第二封邮件，同时抄送相关人员的直接经理。以此督促相关人员尽快更改 ODC 属性，以便该缺陷被标识为“已校验”；“N/A”表示该缺陷为无效缺陷。

• 会议纪要：记录、传达每次例会的情况，便于日后查看和跟踪。下面以作者参与的项目为例，会议纪要内容包括如下方面：
  • 参会人员：参会人员名单。
  • 公告：通常是上次会议待解决事情的进展或结果的说明。也可是重要的通知。
  • 本次会议讨论内容：本次会议讨论内容详情。
  • 行动：
    • 根据会议讨论的结果，有些是需要在会后付诸于行动的。这样就需要把每个行动的内容和负责人记录下来，以便下次会议进行跟踪确认。下面举例说明。如果本次会议记录了如下两条行动：
      • 某某去联系缺陷管理工具的管理员，添加一个额外的属性来记录缺陷是否已被校验过；
      • 某某去邀请 ODC 专家 David 来参与我们每周的例会，帮助我们解答校验过程中遇到的问题。
      在下次会议开始的时候，首先要确认上次会议中这两条行动是否已经实施。并把进度或结果在本次会议纪要中的公告部分进行说明。
• 参考资料的链接：
  • 关于 ODC 校验工作和 ODC 分类说明的参考资料链接。

对于校验小组长来说，如何更有效、更直接的分配校验任务？

仅仅在 wiki 中列出工作分配表，虽然也可以进行任务分配和进度跟踪，但由于并没有跟缺陷管理工具相关联，所以需要校验人员根据表 1 中的缺陷编号，逐一在缺陷管理工具中进行查找。显然这样很浪费时间，也难免会在查找过程中发生错误。因此在缺陷管理工具中直接分配任务是更合适的办法，同时利用表 1 中所示的 ODC 校验工作分配 / 跟踪表进行进度跟踪。

在作者从事的项目中，我们采用在缺陷管理工具中增加一个名为 ODC Validator 的属性，如图 4 中所示。来供校验小组长在分配任务时进行选择。这样校验人员在登录缺陷管理工具后，直接查询 ODC Validator 属性为自己名字的缺陷列表即可。

图 4. ODC Responder 选项签中新增加属性 ODC Validator:

文章来源于领测软件测试网 https://www.ltesting.net/