测试与开发人员的战斗

作为一个测试老兵，经常听到有测试新人抱怨，需要和开发人员进行激烈的讨论，感觉像打仗一样。其实，测试人员和开发人员的战斗不仅仅在小公司有，在大型软件公司也是比比皆是。这种战斗不仅仅发生在开发周期的初期，也发生在开发过程中，甚至在产品发布后，很多产品质量问题的追责也会引入新的战斗。

作为一个老测试工程师，也聊聊开发人员和测试人员的战斗，谈谈自己的心得吧。

先说说战斗的种类。

1）缺陷（Bug）属性之战

对于一个缺陷，开发人员和测试人员有不同意见，例如，开发人员说是“建议”，测试人员说“代码缺陷”；开发人员说是优先级3的，测试人员说是优先级1的；开发人员说不能重现问题，测试人员说曾经出现，必须调查。

2）产品指标目标之战

对于一个产品达到什么要的指标，也是测试人员和开发人员讨论的热点。例如，测试人员说性能必须到达200毫秒，但是开发人员常反驳说500毫秒是合理的目标。虽然，在需求说明书中，产品经理规定了产品大的指标，但是一些执行的细节目标却没有仔细规定，这往往是开发人员和测试人员的战场。

3）质量任务之战

质量保证的任务有很多种，包括写单元测试，收集试验数据，搭建环境，功能测试，安全检查等等…. 那么这些任务究竟是如何安排的，是测试人员做还是开发人员做，不同公司有不同的文化，有不同的开发测试人员比例，导致其分工也不一样。有时，开发和测试对于一些任务的责任人也有着不同看法，这也往往会成为战斗焦点。

4）代码质量之战

代码的质量的好坏，是否可接受也是在代码审查时经常讨论的，比如一些异常的处理，是否合理，覆盖面是否全面。

测试人员的战略和战术

很多测试人员在这些战斗中不容掌握主动，以下就是一个老兵的一些经验，希望能够帮助测试人员在战斗中更好的赢得主动，为高质量软件产品赢得胜利。总的来说，对于测试人员说，是保护用户的体验，因此有机会得到更多人的支持，换句话说，测试人员”不是一个人在战斗“。另外，”多算胜，少算不胜“，讨论前尽量多准备准备。

1）多引用用户体验，多引用竞争对手的数据作为论据

在讨论中，列举的论证时，如果测试人员的论据是以“我认为…..”，这种论据通常是不是很令他人信服的，因为开发人员也可以说”我认为…不是这样的..'’。因此，在讨论中，应该多引入用户体验的数据作为支持论据。另外，可以多多列举竞争对手的数据，也是很有说服力的。

举例来说，一个用户登录界面，产品需要3秒钟登陆了，测试人员认为很慢，开发人员认为可以接受。那么，测试人员可以指出，在这种设计下，用户体验很差的，用户需要更好的性能，同时可以列举一些竞争对手的登录时间作为参考。少说”我认为…..”，多说用户体验差的具体数据。

2）争取项目经理或则产品经理的支持

产品经理通常也是产品质量的坚决拥护者，因此产品经理通常都站在测试人员一边。如果在用户体验上，开发与测试人员的观点僵持不下的话，可以考虑将产品经理引入讨论，通常产品经理会支持更好的用户体验，而站在测试人员的一边。获取产品经理的支持，注意引入的次数与频率，如果引入过于频繁，有时容易导致开发人员的不满。

3）存同求异

对于一些非关键的争论点，例如，一些与产品质量没有本质影响的决定，测试人员可以与开发人员保持不同的观点。对于这些不同观点，不会影响项目的进展和产品的质量。

4）速战速决

孙子言”兵贵速，不贵久“。测试人员的工作通常繁重，如果花大量时间和开发人员争斗，往往得不偿失的。其实大部分讨论，在前5分钟，双方都已清楚的表达了观点，列举了大部分的论据，因此5分钟后的大部分讨论，都是这些观点和论据的反复陈述，通常无法通过论据本身说服别人。因此，我提倡对于单个问题的讨论，不应该超过5分钟，测试人员应该控制节奏，5分钟内结束讨论。如果5分钟内仍然没有结论，测试人员可以主动结束这次讨论：对于原则性的问题，考虑另外收集更多的论据（数据），获得更多人的支持，另找时间再和开发人员继续讨论；对于可以权衡的问题，可以考虑相互让步，已得到双赢；对于一些小问题，可以考虑抓大放小。

好了，说了这么多，都是纸上谈兵。其实战斗的技巧主要是来源于实践，希望大家能够在战斗之后，仍然能保持一个好的心情，另外减少激烈讨论所花的精力，并且提高有效性。

 

一场交锋：测试与开发的矛盾
距离我的第一份正式工作的入职，已经两周了。第一周的时候，测试经理让我做已经成型的产品测试。然后第二周就让我进项目组跟进度做测试了。在这个项目组的测试成员只有两个，都是刚刚入职的，本人和另一个有5年经验的测试主管。
话说，俺俩都是新来的，自然凡事小心翼翼，但求无过。而在公司的项目中有些模块是引入诸如OFFICE等Microsoft开发的平台，似乎是可以不用测试的。于是有以下几种矛盾存在：
1、当测试人员提出BUG后，开发人员打回，说这是Microsoft平台的模块，不予修改。而实际上呢？今天项目经理也提到了，可以用一些方法弥补这些BUG，使功能更加健壮。
2、因为没有安排一些培训，并且需求分析阶段我俩并没有跟踪到位。使得一些产品功能，很难理解正确，甚至无法正确的使用功能，更遑论做测试了。于是，看主管和开发人员面红耳赤的交流，我就在心里构思着，这事如果我是主管该怎么做呢？
大概就是这两类矛盾，最近搞的蛮紧张的。而且，这个项目按照进度已经该给客户部署了，但依旧有些功能没有开发完，导致主管很火大。这种情况下都快交付了，测试工作还没干完，算谁的？
根据以上的情况，我也总结了两点。可能与前辈写过的东西蛮相似的，但多少也是个人体会吧。
1、多读文档，多记要点。解决开发与测试的矛盾好比律师之间打官司，先要站在正义的一边，依据某某文档某某页的某某段话，这个功能应该如是实现……诸如此类。公事公办嘛，只要占着个“理”字，事情就好解决了些。
2、积极跟进项目进度，尽可能为测试争取充足的时间。这次项目因为我和主管都是刚进公司的，居然只给了似乎还不到一周的时间做测试，实在是有点囧。算是考验么？是不是也算是欺负新人呢？但是在以后的时间里，还是要多多向项目经理、开发经理了解、跟踪并及时反应项目进展情况。总是在最关键的时候使用项目总体最少的时间段，实在不明智的很。似乎是中学寒暑假写作业才会做的事吧，最后几天才抓紧赶工写。
这一下，把我和主管都有点弄郁闷了。不过呢，这只是社会的一个脚步，看到的也只是冰山一角。套用一句老话：“让暴风雨来的更猛烈些吧！”

 

遇到这样的开发人员该怎么办

最近看到有个同学的blog很火，题目很吸引人，今天我也忍不住其实早已忍不住想写点关于这方面的，但是侧重点还是不同的，无超越之想法，呵呵。
我相信大家工作中遇到的不都是你期望的可以达到很好共识的开发同学，如果你遇到了与你一拍即合的开发人员，那你是幸运了，当然我也是幸运的，呵呵，那当遇到了以下一些情况的时候你是怎么做的？
遇到这样的时候该怎么办？
我们都知道，开发不能自测，因为会受自己的思维所限制，这个与工作性质也有关系，就像长期做测试，你会发现生活中其实很多时候你的各种疑问，各种猜测都是在受测试思想所潜移默化的影响着了，那么开发也同样，开发同学在每次接到需求时，第一时间脑子里出现的问题就是，这个需求是否能实现，然后就是“这个需求如何来实现”，可能有些开发同学就直接飞到代码里了，我身边就有这样的例子，即使跟pd沟通，也会直接跑到代码里了，这样会出现，其实你本来就只想要一个是或者否，或者一个小问题，那么在与这样的开发同学确认时你可能需要3-5分钟的时间，测试一个需求，过程中肯定会有很多沟通，而如果遇到这样的情况，可能你的一些时间无形中就被消耗掉了。
针对遇到这样的情况时，首先你要清晰的表达出你想要什么样的结果，可以直接说出你不需要了解的内容，然后再让对方给出答案。当然如果你对系统实现还不了解，或者你想从与开发的沟通中找到你可能遗漏的测试点，那就需要耐心听开发的解释，的确会有很多新发现。
遇到这样的时候该怎么办？
由于测试人员在提交bug之前都会先跟开发打个招呼，确认下再提交，开发同学比较忙时，不会马上解决，所以你会先提交bug，但是这样的习惯会导致有些开发同学不愿意自己去qc里查看，而是直接在群里问测试同学。甚至有的会直接跑到测试同学面前让测试同学重现下，有时可能测试同学也没介意，那就重现下，但是如果遇到的次数多了，相信也是件不爽的事情，而且也会给开发养成这个习惯。
所以测试同学的确需要坚持原则，提交专业bug的目的就是为了让开发同学自己去清晰了解bug重现的条件。如果再来问你这个bug，那就说明是你的bug没有描述清楚。所以尽量减少已经提交的bug再次被打扰的情况，我们需要提高bug描述的专业性。
遇到这样的时候该怎么办？
测试人员提交bug时难免会出现误提bug，比如是脏数据引起的，比如是当时环境有问题引起的，不知道是不是有些开发同学遇到这样的无效的bug比较多还是？会发现不管你提的问题是什么，他都会第一句问你“是脏数据引起的吧”，或者是哪个应用无法提供服务引起的吧，甚者会直接说就是由于某个原因引起的，相信测试人员会不爽，但是相信也会条件反射成为习惯，有些测试同学心虚，会再次操作下看是否的确是脏数据或者当时环境问题引起的。但是我相信是这种无效bug是很少很少的，如果你遭到了多次这样的被怀疑后，也会很不爽。
针对这种情况我们首先要以同理心来体谅对方，所以为了不浪费开发同学的时间在无效bug上，我们需要对我们提的每个bug要负责，而且最基本的是要首先要自己做过排查不是脏数据引起的，测试人员也需要提高识别bug的能力，不要问题都先提出来，让开发确认一下是否有效然后才提交。如果你还在这样做，那你需要好好考虑下咯。
在我们保证我们提出的bug绝对有效的情况下，开发同学还在这样反问的时候，你可以毫不犹豫的跟开发说是的，让他自己在看下bug描述，而不是直接在你电脑上给他重现一遍以证明你是对的，当他与你合作几次之后，他也了解了你的工作习惯，也了解你提的bug都很ok，他自然也会遵从你的习惯。
遇到这样的时候你该怎么办？
测试同学最关注的是开发提交代码的质量，最希望开发提交的代码有极少的bug，至少最基本的情况都是正确的，但是希望很美好，现实很残酷，希望达到这样的状态，就需要开发有很强的代码质量意识，质量意识说说是很空泛的，开发有时也的确会说是由于太忙，没时间自测，所以才… 但是这些都不是借口，其实开发说忙，他的确完成了这个日常，但是其实无形中把工作转嫁到测试的时间上了，所以开发做好自测同时也是在减少测试和开发反复修改bug的时间，那有什么办法可以提高开发提交的代码质量呢？
说道办法，目前想到可实施的也是采用冒烟测试，列出该日常基本测试点，至少保证最基本的需求实现是无问题的，开发冒烟通过，在提交给测试，如果开发没有自测会怎么样呢？有什么后果呢？的确我目前也无法说会有什么后果，但是至少在心里上让他觉得不好意思。当然我相信应该没有觉得好意思的呵呵
以上是列出比较典型的，大家工作平时工作中或多或少都会遇到的，当然解决办法也会有更多，我们最希望的是在处理好开发和测试的友好关系下又能提高工作效率。
思考：开发人员为什么拒绝修改我的缺陷

缺陷是测试过程中测试人员的重要输出，它不仅是和其他项目利益相关者进行沟通的桥梁，也是证明测试人员测试能力的重要手段。但是，在实际的测试过程中，测试人员提交的缺陷常常会被开发人员以各种理由拒绝。
为了减少被软件开发人员拒绝的缺陷的数目，我们首先需要了解为什么开发人员会拒绝测试人员提交的缺陷，或者说他们为什么不愿意花费时间和精力解决测试人员提交的缺陷。本文将从几个不同的视角分析缺陷被拒绝的原因，从而有针对性的提出一些建议，帮助测试人员尽量减少被开发人员拒绝的缺陷的数目。根据笔者的经验，开发人员拒绝研究和修改缺陷的原因是多方面的，例如：
● 开发人员无法复现缺陷（无法复现）；
● 缺陷报告中提供的信息不足，或者复现缺陷需要奇怪而复杂的步骤（难以理解）；
● 开发人员认为是系统的一个功能点，而测试人员认为是一个缺陷（缺陷还是功能点）；
● 开发人员不理解测试人员的角色和职责定位（测试人员的角色）；
1）缺陷无法复现
开发人员拒绝研究和修复测试人员提交的缺陷的第一个可能理由是：这个缺陷我无法复现，或者这个问题在我的环境中并没有发现。
在测试过程中，测试人员经常会碰到一些不可复现或者很难复现的问题，特别是在进行非功能性测试的时候，例如：稳定性测试、压力测试、满配置测试、兼容性测试等。通常来说，这些难以复现的问题，其导致的结果一般都是比较严重的，例如：系统性能不稳定，系统随机重启等。同时，这些问题常常也是用户最关注的地方。假如用户在使用过程中出现这样的严重问题，将会极大的降低用户对产品的信心。
即使是难以复现的问题，建议测试人员还是需要提交缺陷报告。只是，测试人员在提交缺陷报告之前，需要采取一些合适的策略和建议，尽量为开发人员定位和修复这样的问题提供合适的信息，帮助他们尽快解决问题。我的建议包括：
● 首先，测试人员养成这样的习惯：打开系统的调试窗口（假如系统提供），时时记录测试过程中系统的打印信息。发现系统的异常表现的时候，测试人员就可以捕获其中异常的系统打印信息，这些信息可以帮助开发人员跟踪和定位缺陷发生的原因，从而有利于开发人员解决这种类型的缺陷；
● 其次，测试人员碰到系统的异常表现的时候，可以先判断该问题是否可能难以复现。假如觉得难以复现，测试人员可以先保留当前的测试环境，要求开发人员到现场来定位和分析其中可能的原因。假如开发人员可以从当前的环境中分析得到可能的原因，那么测试人员编写缺陷报告就可以轻松得多；
● 第三，测试人员报告不可复现的缺陷的时候，应该在缺陷报告中明确告知开发人员不可复现或者难以复现，从而避免在有限的时间和资源情况下，开发人员过多的将精力放在这样的缺陷修改上面；
● 第四，建议测试人员提交难以复现的缺陷，组织内可以不断的收集和分析难以复现的缺陷数据库。定期浏览这些缺陷，并进行集中的分析，可能会在不同的缺陷描述中发现一些共同的或者可能有联系的信息，有助于问题的解决；
2）缺陷报告难以理解
开发人员拒绝测试人员提交的缺陷的第二个可能理由是：缺陷报告中提供了太多的内容和信息，开发人员甚至不知道测试人员想说什么，也很难了解测试人员想阐述的问题是什么。
缺陷报告是测试过程中测试人员的重要输出。很多的时候，项目利益相关者通过缺陷报告认识测试人员。好的缺陷报告可以为测试人员带来良好的声誉，而差的缺陷报告可能会为利益相关者带来额外的工作。如果测试人员的缺陷报告，浪费了项目利益相关者太多的时间和资源，他们潜意识中就会抵制和拒绝他们的缺陷报告。
编写良好的缺陷报告是测试人员应该具备的几个基本技能。高效的缺陷报告，对测试人员而言具有重要的意义，除了可以减少被开发人员拒绝的缺陷数量，也有助于提高测试人员的可信度、改善开发人员和测试人员之间的合作关系。
好的缺陷报告是测试人员在测试过程中发现了什么，而不仅仅是告诉开发人员我们做了什么。这对于编写高质量的缺陷报告很重要。另外，我们在编写缺陷报告的时候，还应该使缺陷报告尽量具备以下特征：
● 精简的：缺陷的描述应该是清晰而简要的。首先在缺陷报告中剔除不必要的语言。其次，不要增加无关的信息。在缺陷报告中包含所有缺陷相关的信息，并且确实是相关的。多余的信息只会增加缺陷描述的含糊不清；
● 正确的：提交的问题确实是一个缺陷。假如提交的缺陷最后证明是由于理解错误或者配置错误引起的，测试人员将在开发人员面前失去可信度，同时会对彼此之间的沟通带来一些影响；
● 隔离：尽量寻找简短的步骤来复现缺陷，即将缺陷进行隔离。例如：哪个模块中发生了问题？是哪个输入条件触发了这个缺陷？是哪个动作引起了这个失效等。对问题的隔离定位能力，很大程度上可以为测试人员加分，同时可以提高大家的测试效率和项目整体的效率；
● 推广：确定系统其他部分是否可能也存在同样的问题，以及使用不同的数据时是否也会出现这种问题等等。测试人员在缺陷方面的推广能力，可以帮助节约开发人员修改缺陷的时间，同时提高缺陷解决的效率；
● 复现：确定系统是否可以复现这个问题，需要什么样的步骤输入来复现这个问题。对于能够复现的问题，提供简单的步骤和输入。对于难以复现的问题，尽量提供一些告警信息、日志信息给开发人员，或者问题发现时，可以和开发人员一道进行跟踪调试和定位。对于实在无法复现的问题，在缺陷报告中明确说明，并且在后续测试中留意跟踪；
● 证据：如同写测试用例需要测试条件一样，在缺陷报告中，测试人员需要提供测试的期望结果和实际结果，参考文档是什么？；
除了上面的要求之外，测试人员在编写好缺陷报告之后，假如时间允许，可以请求有经验的测试人员或者测试经理，在提交缺陷报告之前阅读一遍。这有助于缺陷报告质量的提高。
3）缺陷还是功能点
开发人员拒绝测试人员提交的缺陷的第三个可能理由是：他们认为这是一个正常的功能特性（或者功能点），而测试人员认为这是一个问题。