测试(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.
