测试开发的"战斗"---我不是一个人在"战斗"

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

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

先说说战斗的种类。

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

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

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

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

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

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

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

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

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

4) 速战速决

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

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