理论上这都是非常有道理, 但是如果这些人如果没有亲力亲为地在这个项目中做一些具体事, 他们怎么能“设计” 出高质量, 有实际意义的测试用例呢?
有时分工导致链条过长, 信息丢失。一个开发者对自己写的程序有什么潜在问题还是很有感觉的, 有些问题可以用文字表述出来 (如果开发人员有耐心把文字写出来的话), 有些问题是一些预感… 现在都交给别人测试了, 那好, 让他们测吧, 我也懒得说了。
分工还可能会导致一个软件的灵魂被切碎分给各个 "角色"，每个功能都做得很卖力, 但是整体就是不太行, 明显看出来是费了老大的劲给强行“集成”起来的。
问题: 无明确责任的分工
在我写第一本书的时候, 编辑部告诉我他们会对书稿进行初读, 二读, 三读等流程, 每个环节要花几天时间。作为出版界的外行, 我理解这些都是QA 的阶段, 等过了二读的时间, 我就发信去问， 负责二读的专业人士找到了什么问题了? 得到了语焉不详的回答… 一个问题都没找到? 但是从编辑部的回答来看, 二读不二读, 似乎没什么影响。其实这本书的小问题还很多，在出版之后, 都陆陆续续被读者报告了。
有时候出于种种考虑, 人们会把一些善良但是能力有限的同事安排在一些位置上, 扮演一些角色, 例如“二读”什么的。或者有些角色就是由一些人占据着, 但是大家对这个角色也没有什么明确的要求。这是许多问题的根源。
我们对这个角色有什么可以量化, 可以核查的责任要求?