为什么要“各方全责”

　　曾几何时，在一个开发人员独自负责一个模块的代码编写和测试的时候，软件的质量基本上就依赖于这么一个人。那么在出了任何问题之后，撇开管理不说，责任就100%的落在这个开发人员的身上。但是现在绝大多数情况下，编码和测试已经不是同一个人或者团队了，我们经常能见到在编码同事和测试同事沟通的时候出现如下几种场景：

　　A、这代码写得这么烂！测试已经尽力了，出了什么问题不要怪我……

　　B、测试的价值就是守住质量最后一道关，所以你们要竭尽全力来测试，否则你们要……

　　C、我们一起来看一下这个问题吧，不然到时候出了问题大家都得负上一些责任的……

　　D、（省略N字）……不要这么说，一旦出现什么生产事件，你我都得挨板子，所以还是……

　　显然前两种的态度是更倾向于用对方的责任或过失来淡化甚至隐藏自己在这件事情中所扮演的角色，认为结果导向中的差错责任应该由某一方来承担。而后面两种情况表明编码同事和测试同事应该都为软件质量负责，C更倾向于把责任摊分，如果关联方是3个，那么每人或者每一方应该承担33.33%或者由张三来承担40%，其余两方各承担30%……如是种种摊派；D则倾向于让每个参与到软件开发过程中的人都承担100%的责任。笔者自己选择D，因为笔者认为编码人员和测试人员应该都为软件质量付出努力，担负全部责任，而并没有责任大小之分。为了简化描述，我们下面就以沟通只有编码和测试两种个体为例，来分析一下为什么“各方全责”好过责任分摊。

　　首先，责任这种东西，到底如何量化呢？如果说甲方承担60%，乙方承担40%，那么一般都是对于经济损失和相关可量化的罚则来说的；但是软件的质量问题一旦出现，是否就要对编码和测试等相关人员进行经济处罚呢？显然不现实！所以这种责任分摊对于软件质量保证来说基本没有可发挥作用的空间。另一方面，责任对于每一个人来说都是0与1的关系，如果没有责任那么就说明与此事彻底没有联系，否则一旦参与到这个过程中来，就必须为自己所服务的对象负责，那就是保证软件的质量，所担负的责任始终是1……也就是“一份责任”，作为一个最基本的单元，它就是百分之百。所以，笔者认为在软件开发过程中，软件质量问题的责任没有小于百分百的任何一种比例。

　　其次，对于软件测试来说，它实际上是一个离不开沟通和互动的活动过程，从开发需求评审、设计评审到测试需求分析、测试设计，再到测试执行、问题确认和缺陷修复，都离不开编码人员和测试人员的沟通。而大家知道，人与人沟通中的每个个体都应该为自己的行为负上全部的责任，因为我们每个人的信息传达和捕获都依赖这个人自身在沟通中的行为：正确清晰的表达、仔细的倾听和积极的反馈等，如果任何一个环节没有做好，都将可能产生不必要的问题。而从主观上来说，这些问题恰恰是由于我们表达的不够清晰或者倾听的不够仔细或者没有给出合理的反馈等原因所导致的。所以每一个单个的个体都应该为自己在协作中的行为和对对方行为的认可而负责，也就是说每个人都应在沟通中为人为造成的失误而负上全部的责任。而对于软件测试过程中的沟通来说，无论是需求没有描述清楚还是用例设计不够完善，都能够从沟通中反馈出来；如果没有做到这一点，那么就是沟通和协作的失误。

　　软件质量保证显然不只是编码和测试两方面的工作，以目前软件生产的普遍模式，牵涉的关联方很多，包括用户、BA、EA、SA、Coding、Tester等等。如果在协作过程中每个人都自己包揽百分之百的责任，那么就成了“各方全责”，主观能动性将得到最大的发挥，对于软件质量保证想必绝不是一件坏事。不过想法虽好，要做到“各方全责”却不是一件简单的事情。

　　实现“各方全责”——严以待人

　　在沟通过程中，如果出现自己表述或者行为的过失，自然需要为自己的过失付出一些代价去改正，而在获取对方所表述的信息或者鉴别对方的行为的时候，也要进行合理的评判。如果只是语言的表达，那么我们可以通过开放式的问题进行反复的询问或者通过复述对方的观点来确认信息的准确性。但是对于鉴别对方行为的合理性，一般“有德之人”都信奉“严以律己，宽以待人”这个八个字，认为无论对方做的对还是不对那都是对方的方式方法，我只要管好我自己的事情就好了！其实这也是一种不负责任的行为，“严以律己，宽以待人”这八个字的真正含义是在出了错误之后应该不要太过苛责外在因素，多找主观因素或者说自身问题。但是我们通常却把它理解到一件事情的每个阶段去了，在事情还没开始进行或者正在进行的时候抱着这种信条，并不认为帮助对方提高质量也是自己的责任，让协作变得始终不能尽善尽美。换句话说，如果我们合作对象的工作质量可以提高，我们就必须帮助他们提高，如果他们犯了错误，我们也必须要通过一些渠道告诉他们，所以无论自己或者对方如果有任何问题，那么责任在我们自己。那么为了避免出现种种不必要出现的问题，我们在“严以律己“的前提下或许应该学会“严以待人”。

　　在测试过程中，测试人员有权利和义务对软件的设计进行评审，及时发现和预防其不合理方式的使用；同样开发人员也有义务和权利依据需求对测试需求分析和测试设计结果进行评判。举个例子，我们系统有一个补丁需求需要实现一个数据库操作（JOB）的效率优化，对优化方式和测试方法问题进行了探讨：

　　测试：看了一下你们提供的需求说明，能否再具体说一下你们的优化思路和自测结果？

　　编码：其实整个操作过程中的SQL效率并不差，你可以自己看看执行计划，只是随着业务量的喷涌式增长，数据量越来越大，好像这个功能都不太适合用做OLTP来处理了，不过因为业务方对时效还是有一定要求，就只好先通过限定入口条件来减少运行的循环次数了。我们目前自己测试发现效率因为数据量水位下降而快了40来倍，总的来说达到预期了。

　　测试：怎么限定？把目前实际需要操作的数据类型给筛选出来，其他的通过改程序把数据筛选掉不管了？

　　编码：是啊，你有什么好的想法么？