为什么开发与测试老掐架呢

让我们思考几个常见的问题:

  • 软件测试的目的是什么?
  • 开发人员能否构建出没有Bug的完美软件?
  • 测人人员和开发人员是什么关系?
  • 软件测试能否保证软件质量?

先闭目冥想五分钟吧,然后可以尝试着回答上面的问题。

计算机先驱 Maurice Wikes 回忆起 1949 年他在英国剑桥工作的情形,在拖着打孔纸带上楼给雏形计算机 EDASC 装载程序时,他看到了自己的未来:

我强烈的意识到,生命中剩下的好日子,都将耗费在给自己的程序找错误上头。

Maurice Wikes告诉我们,没有完美的软件。

我在我的微信订阅号“程序视界”里发布过一篇荐书文,推荐了温伯格技术思想三部曲中的《颠覆完美软件::软件测试必须知道的几件事》。在这本书里,温伯格也告诉我们,没有完美的软件。所有的开发和测试人员都应该读读那本书。

温伯格在《颠覆完美软件》中几乎讨论所有常见的与软件测试相关的概念、问题和指导思想,所以,在这篇文章里,我只能来吐槽啦,我将从以下几方面列一些常见的现象,希望能引起大家的思考。

  • 测试和开发的关系
  • 流程与标准
  • 资源
  • 态度

测试和开发的关系

测试和开发是对立的吗?

从处理Bug的角度看,似乎可以这么说。开发人员既生产代码,也生产Bug。因为开发人员不可避免地会生产Bug,所以测试人员必须存在,以便在软件交付之前尽可能多地检出Bug,保证交付给客户的软件质量更好一些。一个产Bug,一个挑Bug,看起来似乎是对立的。

在现实中,很多测试团队和开发团队也正是因为这一点而搞得关系不和,甚至真的对立起来。请回想一下你周围发生的与开发和测试相关的事儿,看看有没有遇到过下面的情景:

  • 开发说,测试净找麻烦,客户跟本不可能像他们那样使用软件
  • 测试说,问题总是会在看似极端的条件下产生,用户总是会不经意触碰到看似极端的不可能出现的条件
  • 开发说,测试花在异常情况下的精力比测试主流程还多,不知道轻重缓急
  • 测试说,开发从来不考虑测试的感受,连测都不测就扔给我们
  • 开发说,我都测了,还要测试人员干什么
  • 测试说,这么明显的问题你们都不测一下,把我们测试当垃圾桶啊
  • ……

许许多多类似的问题,让开发和测试的关系从扑朔迷离、相爱相杀走向对立。我见过开发和测试搞冷战某人遇见某人侧脸而过,也见过测试经理和开发经理打架,还见过高层领导故意让测试团队和开发团队关系紧张以为这样可以提高测试效率也能给开发压力最终会产出更高质量的软件……

实际上,测试和开发拥有同一个目的:让软件更完美。测试和开发的关系,是一个问题的两面,应该是相辅相成和平共处的。测试不是为了挑刺儿,他提出的问题也不针对生产软件的开发人员,而仅仅是在努力想让开发人员的产出物看起来更好用。只要开发不将测试提Bug这个行为看成针对个人的行为,一切就有了美好的前提。

否定软件,并不是否定开发软件的人。这是开发和测试都需要明确的一个原则和前提。

还有的人认为开发和测试之关系类似皮与毛,皮之不存毛将焉附?所以有的开发也会因此而有优越感:没我们写软件,你们测试早下岗了!可是,开发不写软件,开发也下岗了耶!

感谢开发的不完美,让测试可以有事可做并练就慧眼。

感谢测试的认真细致和耐心体贴,让开发可以发现自己的不完美并有机会提升自己——那些说我软件不好的,都是为了我好。

资源

别动我们测试的服务器,你们自己搭一个!

我们没环境,不用你们的用谁的?

谁把我们的测试手机拿走了?你们申请一个嘛,老来占我们设备。

谁在用我们的账号?招呼都不打!我要用,赶紧退出来!

有时开发和测试之间也会有资源上的冲突,要有努力的有创造性的解决(我可以负责任地说,装黑苹果不是好办法),不要让大家伙的工作卡在环境上,这是管理者要解决的基本问题。我见过很多非常棒的一线经理,在现实制约下,主动把自己的手机、iPad都贡献出来当做测试设备。这也是解决资源问题的一种办法哦。

流程与标准

你身边的人员会这么抱怨吗:

  • 开发根本不看我们的测试用例,评审邮件从来就不回复
  • 我们一报Bug,开发就说用户根本不可能这么用,还说不知道我们怎么会这么测
  • 送测单里根本不写测试范围或者寥寥几句跟没写一样
  • 开发调整设计从来也不告诉我们
  • 为什么产品经理和UI只和开发讨论需求变更?
  • 为什么发布计划里不给测试预留测试时间?
  • 为什么开发写完代码测都不测就扔给我们?
  • 为什么客户那里发现了问题老问是谁测的、为什么没测出来?
  • 测试老是一声不吭就把Bug优先级设置为Major
  • 测试总是把大量时间花在用户根本不可能用到的功能上
  • 测试分不清哪些什么是重点,你给他说他还老是一堆道理这了那了
  • 测试提的Bug,现象描述也不准确,重现步骤也没有,有的根本就知道是不是误操作
  • 测试老来打断我,一会儿叫一下一会儿叫一下,根本没办法专注开发
  • jira上的Bug重复率太高,一个问题提N遍,难道就不能合并一下?
  • 测试发现Bug,一声招呼都不打就直接告诉老板了,搞得我很被动
  • 测试就是专门挑刺儿的,有劲不往正地儿使,你倒是测测用户常用的功能啊
  • 那么简单的Bug都能流出到用户那里,真不知道测试怎么测的
  • 开发老嫌测试报告数据不漂亮,逼着我们调整

Ok,如果你身边的开发和测试从来没有过类似的问题,那很好,恭喜你,看来你们的团队人nice协作也很顺畅,棒棒哒。

假如你身边充斥着这样嘈杂的抱怨,那说明什么呢?开发、测试、发布这一套流程有问题?还是团队缺乏明确的指向来引导大家向积极、有效的行为靠近?

流程和标准总是有待解释的,再好的规则,歪嘴和尚也能把它念斜……

我们随便挑一个问题吧:为什么开发写完代码测都不测就扔给我们?这个问题普遍存在,它反映出的是程序员和测试人员的工作边界难以界定的矛盾。

程序员会说,我都测一遍,还要你们测试做什么?

测试会说,你测都不测,冒烟都过不了,有没有责任心?

程序员说,要我写测试用例,搭各种环境,遍历各种正常、异常逻辑,我还有没有时间写代码了?

测试会说,我们测试是垃圾桶吗,什么烂玩意儿都直接扔给我们,我们的时间就那么不值钱?

开发会说,测试本来就是干这个的,你不测谁测?

……

像这样的问题,能制定一个标准,说明什么样的逻辑开发要自测覆盖什么样的逻辑可以交给测试来测?能画一条三八线吗?

不能。所以,这个时候,靠谱的一线管理者就显得很重要。如何创造性的发现适合团队的方法来让大家顺畅地协同工作,比标准、制度更重要,这往往依赖于技术管理者的能力和团队成员的意识。没有普适的方法,只有适合这个组织的、此时此地的策略,加油吧,在战斗中摸索出最适合当下的道路。

那什么是靠谱的一线管理者呢?

温伯格《成为技术领导者》一书中对领导职责的定义如下:

领导的职责就是创造这样一个环境,每个人都能在其中发挥出更多的能力。

如果一个技术领导带领的团队,大部分人都能专心做与其能力适配的事情而不用整天泡在与本节前面所列类似的问题里,那他基本上就算是比较靠谱了。

至于像给测试预留多长的测试周期、调整设计要不要通知测试、需求调整要不要测试参与等问题,合理的流程和标准可以起到很大的辅助作用,技术领导者只要依据合理的制度,引导大家有效参与,就可以化解。

态度

场景一:

测试MM对阿猿说发现了一个Bug。

阿猿矢口否认:不可能,绝对不可能!

MM:真的有Bug,你过来看一下!

阿猿:我都不用看,在我这儿好好儿的。

MM:你来看一下嘛……

阿猿:看什么看,肯定你环境问题,动什么东西了吗?重启了吗?

场景二:

测试MM想在jira上提个Bug,先在QQ上对阿猿说:有个Bug,你过来看下?

阿猿:忙着呢,焦头烂额的。

MM:一分钟都用不了,你来看下吧。

阿猿:思路一打断就不好恢复了,等会儿!

MM:你不看我提到jira上了啊。

阿猿:随便,你不就是爱提Bug嘛。

场景三:

测试MM呼叫阿猿:阿猿阿猿,程序又崩溃了,快来看看!

阿猿慢腾腾地起身过来,鼠标点几下:看不出来什么问题,你怎么操作的?

MM:这样点一下,那样,这样,……回车……。

阿猿:重现不了啊,你想办法重现,重现了再叫我,我忙着呢。

MM:……

我曾经画过一张暴漫,以“她发现了一个Bug”为题发布在微信订阅号“程序视界”里,再现类似的场景,感兴趣的可以在订阅号内回复10019查看(点击订阅号底部的帮助菜单里的“所有文章”子菜单也能找到)。

开发和测试的日常工作中,上面的情景不断上演,这其中有一部分原因来自态度。我们有时还能听到类似下面的话:

  • 你Bug里的现象描述根本没用
  • 你根本就没理解这个逻辑,给你说不清楚
  • 测试什么都不懂……
  • 你听我的,我让你怎么测你就怎么测
  • 你这种测法儿,再好的软件都经不起你折腾
  • 用户根本不可能这样用,你们整来整去净瞎耽误工夫
  • 一轮都没测完,你们就给老板说可以按期交付没问题?
  • 你们安排计划时根本不考虑测试,三天,三天怎么可能测得完!
  • ……

有时,有一些开发人员会用技术优势藐视测试,认为测试工作技术含量低,内心认为测试是附属没地位,说话就不太客气……测试会感觉到,反过来也会对开发有意见……就这么,从相敬如宾开始走向嫌怨丛生……

有个朋友的QQ签名档是:没有自我,只有大道。我琢磨,放在软件项目里,也挺适用的。

其实,开发和测试拥有共同的目的:生产高质量软件。具体说,每一个产品、项目、版本都有明确的目标,这些目标是属于开发和测试的,是大家的。我们把共同的目标牢记在心,摆在首位,我们还要想着别人所做的一切,都是针对软件本身,都是在为目标而努力,这样就心平气和多了,就容易从当下的泥沼中超脱出来,求同存异共同前进。



相关阅读

更多文章,请关注微信订阅号“程序视界”(programmer_sight)或我的专栏“漫谈程序员

时间: 04-08

为什么开发与测试老掐架呢的相关文章

互联网产品上线前,做些什么——产品、开发、测试的视角

这阵子,经历了一个做产品以来速度最快的一个项目,太多第一次遇到的情况,从中秋节前到现在,除去校招出去的5天,一直都在赶项目.即使是校招,也是以项目为主题进行群面和创意PK. 每天早上9点多到公司,晚上12点后收工,甚至有到凌晨4点才下班,早上7点多起床,中午还不休息. 赶项目的节奏,大抵如此吧.这不是一种健康的状态,会逐步调整过来. 先说一点特别重要的事情: 无论进度多赶的项目,发布前,请一定内测. 无论进度多赶的项目,发布前,请一定内测. 无论进度多赶的项目,发布前,请一定内测. 这段时间,真

敏捷开发下, 如何将需求分析,架构(软件)设计,开发与测试,一气呵成式的结合且高效的完成 ?

产品开发中,时常会发生类似如图中 "削马铃薯"的悲剧. 悲剧的发生,往往是由于我们只传递了 "要作什么功能"给开发人员.却缺乏了一个有效的且轻量级的实践,能在正式进入迭代开发前,确认开发人员是否真有能力,能将 "使用者的需求"转化为 "可执行的代码"? "场景树" 便是一结合Use Case, Domain Driven Design, UML 的轻量级可视化的敏捷实践. 经由场景树,可确认开发人员,是否已

中小企业可以用docker来标准化开发、测试、生产环境

一.使用 Docker 搭建 Tomcat 运行环境 1 Docker与虚拟机 2 搭建过程 2.1 准备宿主系统 准备一个 CentOS 7操作系统,具体要求如下: 必须是 64 位操作系统 建议内核在 3.8 以上 通过以下命令查看您的 CentOS 内核: # uname -r 2.2 安装Docker # yum install docker 可使用以下命令,查看 Docker 是否安装成功: # docker version 若输出了 Docker 的版本号,则说明安装成功了,可通过以

web接口开发与测试

最近一直在学习和整理web开发与接口测试的相关资料.接口测试本身毫无任何难度,甚至有很多工具和类库来帮助我们进行接口测试.大多测试人员很难深入了解web接口测试的原因是对web开发不太了解,当你越了解开发就会越看得清接口是什么.当然,web开发是比较麻烦,我们很难一下子掌握. 注:不过本文并不是一个零基础的文章,需要你对 Django web开发,requests接口库,unittest单元测试框架,三者有一定的了解. Django快速开发之投票系统 之前分享过一篇Django开发投票系统的例子

android开发及测试工具

1.Buckfacebook开源的Android编译工具,效率是ant的两倍.主要优点在于:(1) 加快编译速度,通过并行利用多核cpu和跟踪不变资源减少增量编译时间实现(2) 可以在编译系统中生成编译规则而无须另外的系统生成编译规则文件(3) 编译同时可生成单元测试结果(4) 既可用于IDE编译也可用于持续集成编译(5) facebook持续优化中项目地址:https://github.com/facebook/buck 2.Android Maven PluginAndroid Maven插

docker技术剖析--中小企业可以用docker来标准化开发、测试、生产环境

一.使用 Docker 搭建 Tomcat 运行环境 1 Docker与虚拟机 2 搭建过程 2.1 准备宿主系统 准备一个 CentOS 7操作系统,具体要求如下: 必须是 64 位操作系统 建议内核在 3.8 以上 通过以下命令查看您的 CentOS 内核:   # uname -r 2.2 安装Docker   # yum install docker 可使用以下命令,查看 Docker 是否安装成功:   # docker version 若输出了 Docker 的版本号,则说明安装成功

从产品、开发、测试论恋爱的不同阶段

1.产品的角度: 当两个人在一起本身就是一个错误时候,说明两个人在恋爱之前没有互相了解对方:没有互相做需求调研导致双方身心疲惫,心灵受到伤害.同时就涉及到需求变更(需求变更流程复杂),需求变更会导致感情受到伤害的两个人疲于应付感情,把自己的感情世界包裹的很严. 注:需求变更适合花心大萝卜. 2.开发的角度: 在恋爱的过程中发现问题,说明前期做过需求调研但不充分.既然在一起了双方就要学会包容和理解,如果遇到实在不可调和的矛盾,那就要采用程序员的思维: A:开发自测,试用场景:双方知道感情问题原因的

需求、开发和测试的“三足鼎立”

在很多电影或电视剧中,大家经常会看到一种代表权利与威望的东西-鼎.古语曰"问鼎中原",可见鼎在当时人们心中地位之高.下面是一张来源于互联网的鼎的图片. 不知大家注意到没有,鼎有三只"脚".大家在几何课上学过,在所有的平面图形中三角形最稳定.看来古人也深知这个道理,做出了有三只"脚"的摆放稳定的鼎.当鼎的任意一只"脚"被去掉时,整个鼎必然会轰然倒下的.也就是说,"三足鼎立"是最稳定的. 在软件开发活动中,可以

到底该不该从开发转测试

到底该不该从开发转测试,我相信很多的人跟我有同样的困惑.那么自己到底合不合适呢?到底该如何选择呢? 我从一下几个方面来分析: 第一点:开发和测试你到底喜欢干什么?也许很多人说,这是一句废话.要是喜欢开发我还考虑转测试干什么,那就直接干开发得了.其实我说的喜欢并非浅层次的喜欢,而是一种由心的判断.其实很多人觉得开发难,测试易所以就喜欢测试不喜欢开发.这只是一种表面的喜欢,而你带着这种喜欢去选择测试我估计你也做不了太远.其实做测试的人要走的远,必须要不仅喜欢开发还要热爱测试.否则,你还不如做开发.