软件质量的卓越之道——全责驱动

软件质量的卓越之道——全责驱动

TIB工作室  刘毅

www.AutomationQA.com

为什么要“各方全责”

        曾几何时，在一个开发人员独自负责一个模块的代码编写和测试的时候，软件的质量基本上就依赖于这么一个人。那么在出了任何问题之后，撇开管理不说，责任就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来倍，总的来说达到预期了。

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

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

测试：这样显然将来如果发生业务需求变动就会很麻烦，如果所支持的业务类型越来越多，那你这筛选不就渐渐失效了么，到时候效率还是得重新优化的，而且到时候优化难度和测试难度就更大了……你们有没有考虑过把需要处理的数据定期抓出来放到一张表里再去处理，避免放到一个过程里运行呢？

编码：……想法倒是可以考虑，不过将来的事情还是将来提需求优化的时候再说吧，这样改造太大了点，风险也大。

 

测试：不行，我们目前这种方法有点饮鸩止渴的意思，将来虽然不一定是我测试这个系统，但是到时候肯定又要从头分析，难度又大，再说将来可能就不是需求而是生产故障了，很浪费大家时间；再说了，你仔细分析一下之后再看看，或许改动没你想象的那么大。

 

编码：你真霸道，好吧，我们回去考虑一下吧，下午下班前给你邮件答复。你测试用例准备得如何了？

 

测试：准备好了，我准备测试XX、XXX、XXXX这几种情况的数据，测试用例清单在早上给你的邮件附件里有，显然我们得把几种常见的数据类型都测试一遍啊……

 

编码：不好意思，打断一下，我觉得你这种类划分好像有点问题吧，XX和XXXX是一种才对，XXX、YY、YYXX这几种又分别是几种不同的分支，无论是改入口条件还是其他方式，我觉得你应该至少把这4种情况都要测试到吧。

 

测试：只是测试性能而已，又不是业务规则变更，有必要么？

 

编码：有必要，你不能轻易相信任何一个编码人员，也不能相信你所测试的只是性能优化，性能优化有时候也会设计逻辑变更，所以还是测试一下吧，呵呵。

 

测试：擦，刚才谁说我霸道来着？好吧，我一会回去补充一下测试用例，唉～

 

编码：嘿嘿，彼此，这个需求先到这，没什么问题我们继续下一个吧……

 

        这种简单的沟通可能大家应该会经常遇到，其实就是测试用例评审过程中的一个真实场景的再现，感觉好像大家在相互“找茬“，而实际上我觉得这正是责任意识的体现。如果双方都不假思索，默认对方所采用的工作方法，那么也许真的会出现生产环境故障，带来经济损失。不过正是因为双方都不想背负故障的责任，所以采用”严以待人“的态度工作，合作中出现冲突很正常，但是假如时过境迁，大家肯定还是会想起当时经常吵架但是合作又很成功的那群人。

        话虽说的简单，但是要大家改变“自扫门前雪”的传统观念，把手伸到协作方的事物里面去，却是一件很难的事情；另外一方面，“严以律己，严以待人”会不会被执行成“宽以律己，严以待人”也是个未知数，所以要全责驱动，还需要管理者制定一些有效可行的激励措施和罚则。我个人觉得可以这么考虑：

 

A. 鼓励在静态评审行为中的互动交流和缺陷产出，同时要避免对静态评审缺陷数量或者相关比例性的数字进行讨论甚至考核，以避免因此而挫伤评审活动的积极性；

 

B.  定期检视测试缺陷和软件开发过程缺陷，如果这些问题能够被提前发现而没有被发现，那么要对静态评审活动的有效性做出合理解释并且给出改进措施；

 

C.  程序问题导致的生产故障和测试遗留缺陷不必区分责任，测试人员与开发人员都要从自身行为中找出不足，并且给出有可行性、可检视的改进措施，定期给出跟踪报告；

 

D.  对于同一种类型的问题，如果重复发生，考虑对相关责任人进行通报批评甚至重新评判其绩效；

 

E.   对于由问题改进而衍生的可推广的，并且能明显改善开发、测试过程质量的措施，要给出表彰和奖励，用以鼓励能够分析问题本质，总结经验教训的人和行为；

 

F.  …… ……

 

结束语

        笔者的意思很简单，那就是软件开发过程中的所有人都要树立自己为软件质量买单的主人翁意识，而并不是单靠技术非常牛逼的编码或者测试人员来进行软件质量的保证。既然是这么个简单的意思，也就没有必要长篇大论了，希望大家也能踊跃发表自己的意见，既然都是砖家，砖头丢过来不用我接也会有人接的，嘎嘎～～～

 

        顺便再罗嗦一句，全责驱动可不是裙带责任哦，希望大家不要弄混了。尤其是在操作过程中，千万不要逮住一个问题就往别的系统或者项目头上扣帽子，要求如何如何，须知每个系统和项目的特征都是不同的，所以弱弱的提醒一下，不要搞无谓的运动哦。