测试(3): 测试与开发

首先,对开发者的测试动机做建模,有如下两类:

  • 一种假设是开发者是主动的,会主动做全面测试。
  • 另一种假设是开发者是害怕和懒于测试。

我们把开发和测试作为角色而不是具体的一个人去看,那么一个人可以是:

  • 开发的角色
  • 测试的角色
  • 开发/测试双角色

而具体到一个软件团队,人员设置上可以有不同的做法:

  • 专职的测试人员,此时需要测试和开发的密切配合。
  • 开发同时做测试、运维所有的活,也即所谓的 DevOps

角色分工,是否有效还是看人是否负责导致有效协作,假设有测试A和开发B,测试目标T,A和B配合的功能组合有:

  • 如果A不负责,B不负责,T失败。
  • 如果A负责(很认真深入测试T,但是并不清楚问题的原因),B不负责(并不积极主动跟踪T),效率低,解决时间被拖延。
  • 如果A不负责(随便测测,反正不是我写的,我也不怎么理解T),B负责(知道A能理解的有限,还是得靠自个深测,自己测,自己fix),可能快,也可能B并不能最佳角度测试出来,B的时间线拉长(=>?加班)。
  • 如果A负责,B负责,密切配合,高效,稳定。

根据团队构成性质的不同,会采用不同的做法,例如:

  • 精英小团队,每个人都能积极主动负责任地做好涉及的相关角色工作,那么可能会倾向于DevOps
  • 普通小团队,那么从软件质量的保证上来说,可能更需要配置一个专职的测试人员积极主动地去推动测试

根据公司的规模大小,可能也会导致不同的选择:

  • 初创公司,人员配置上可能比较简单,但是麻雀虽小五脏俱全。
  • 几十人的中等公司,当小组变多和规模变大的时候,带来管理上的问题,配置上可能会有不同选择
  • 几百几千人甚至几万人的大公司,例如Google、Microsoft、Amazon等,公司在不同阶段可能推行不同的配置策略

最后,可以看下下面这对开发测试组合,这对夫妻一个是开发,一个是测试,他们写了对彼此角色提出的建议:

This particular relationship hits home for us since my husband is a developer, and I am a tester at the same software company.

posted @ 2017-01-15 22:48  ffl  阅读(304)  评论(0编辑  收藏  举报