------当心测试中的不关我事理论

看到这句话后我就一直在嘀咕，我在工作中是否也有这种想法。不过想了半天，也没有想出一个现实的案例，但对于这句话我也有些想法：

从责任角度来看，在国内，目前大多公司还没有完善的软件过程管理制度，一些责任不明确是很正常的。就如我原来呆过的一个部门，经理的办事风格就是，系统上线后出了问题，必定会将所有涉及人员拉过去“罚站”并且加以声色俱厉的“教育”。其实这其中就体现一个道理，软件开发是个团队的事情，出了问题谁都逃不出责任，因此软件测试工作中是不应该出现不关我事的想法的，毕竟就目前来说，测试在人们眼里就是质量把关者。

从沟通与协作角度来看，友好性的沟通、指出问题，能够加强团队之间的合作默契，哪怕合作过程中关系不融洽的，也会在经常性的交流中淡化矛盾。不关我事常常是意气使然。以前在工作过程中碰到一个同事，他给我的感觉是慢半拍而且爱理不理的，主管安排并让我转达的事项，他总是不给明确答复，工作一拖再拖。与他合作的期间我似乎也想不去管他，爱什么时候做你就什么时候做，不过最后我还是不得不时常追踪进度，毕竟是合作，他不动，我也动不了。不过后来交流的多了，相互间了解程度加深了之后，我也渐渐没有了之前对他的那些感官，反而觉得他是个挺有意思的人。

------测试员关注失效，客户才能关注成功

我很喜欢文中的那个希腊神话所说：“测试者在孤岛上，注定要不停地寻找不会存在，也不应该存在的东西，深信成功会为神带来不幸。”

我对这句话的理解是只要信念坚定，哪怕是神也抗不住！自勉～～

只要了解测试的人都知道，证明软件有错才是测试的王道。我也不去牵强地再去组织要关注失效理由了，就简单地举个例子，高速公路两旁都有护栏，而它们并不是行车的功能要求，路面就可以满足行车的需要，但为什么还要护栏呢？通过一段时间的测试可以知道，一般情况下，程序员在主体功能的实现上是不会有什么大的错误的，而经验老道的程序员几乎不会再主体功能的实现上出错，所以个人认为测试如果只是去验证主体功能可用，那么测试这个职业就不会被独立出来并得以发展。

以上的道理很多人都明白，也许和你合作的开发人员也明白，但现实和理论还是有一定差距的，测试员要较好地关注失效还是会被很多因素所限制，我遇到的主要有：

1.      管理机制的不合理、不完善

测试人员和开发人员是开发团队里的最大的矛盾体，在软件开发的过程中出现争论、互不相让是很正常的事情，而如果公司内部没有对应的评判人员（测试或开发经理），或者有评判权的人做了评判但并不重视，那问题就很有可能被搁置。也许这时作为测试者也只有将这个问题提交给需求人员，由其判定并加入到下一轮开发的需求中去了。

2.      项目发布时间紧，任务重

有时一个项目从开始到结束的时间很紧，而在项目计划中又出现了严重的偏差，而最终被牺牲的往往就是测试时间，一般的测试员不可能去和公司的利益对抗，服从是唯一的选择。这种情况下，测试员很难有多少时间去关注失效，通常只能在证明功能可用的情况下，把剩余的时间安排在验证重点功能是否会失效上。

3.      客户性质所导致的质量意识

客户性质这个表述我不确定是否正确，我想说的就是提出开发要求的客户是内部的（集团内部的其它部门）还是外部的，如果是内部的，常常会比较注重软件开发完成的时效，而如果出现小的质量问题，又都通过客服加以解决，有情绪但不会造成丢单危险，这也就造成了团队质量意识的随意，小问题往往不会被关注，常遇到开发人员的回应就是“用户不会这样操作”，当你苦口婆心地阐述万事皆有可能，防患于未然，那么得到的答复会是“等用户提出这个问题再改吧”。

------通过测试并不能保证质量

其实这句话我已经不止一次看到了，每次看到这一思想，我就想把它宣导给我们老板，让他有个正确的认识。但我没有这样做，因为我没有想到好的阐述方式并找到合适的机会，而且对于独裁的老板，他会认为他的思想境界远高于你，就像他的口头禅：“我不想听你解释，你只要按照我的意思去做就可以了”

那些没有认识到“通过测试并不能保证质量”的主管们，在软件出了问题时，第一个想到的就是测试的问题，我对他们的这个条件反射表示理解，但也非常的忧虑，因为这会直接导致最终测试人员的绩效不好，而这也容易形成一个恶性循环。

而团队中也并非仅仅主管会不理解，客服人员最先埋怨的对象往往也是测试人员，因为表象显示的就是客服电话多，客户的问题没有测出来，那责任就应该是测试人员的了。当然对于他们的不满还是比较容易转移的，只要合理的解释说明，那么他们也会理解的。

而要扭转测试员的这一尴尬境地，解释或者自我检讨只能治标，就像作者所说的质量保证要来自整个项目团队，建制、建全软件开发过程，保证每一个节点、每一个阶段的质量，才是治本之道。

附注：

有一篇名为《需求与测试》的文章里有这么一段话：“其实我们有时候会抱怨需求为什么会考虑不周全，可是换个角度想想，我们认可程序会存在bug，那么需求同样也会有。这就像是一场接力赛，需求是第一棒，开发是第二棒，测试是第三棒，每一棒的交接都有上一棒的辛苦付出，也只有彼此信任和共同的努力，才能最终传递胜利。”

------询问一切，但不一定外露

从作者的表述中有两点最基础的观点：

1.      做好测试就需要问问题

对于这一点，本人也只是在一次与需求人员的沟通经历中偶然认识到这一点的。国内很多软件公司在需求部分管理的都比较粗略，有些只是些简单的功能点描述，因此在对这些描述的理解中我们必然会产生大量的疑问。有时需求人员对一个需求的描述存在多种实现情况，我们就要问他们：客户想要的是哪种实现情况？有时新增一个重要功能，在不知道他的实现改动了哪些部分，会对哪些功能产生影响时，就需要咨询开发人员。

而我们换一个角度来说，假如一个软件公司在需求方面做的很好，文档很齐全，也同样有问题需要问，毕竟文字并不能表述出所有内容，需求撰写人也无法将软件的全貌完整展现出来。所以就像文中最后所说的，如果你提不出问题你就最好停下来，因为很可能你对这个软件的需求了解的并不深刻，会将隐患带人到测试中去。

2.      提问需要讲究技巧

对于提问的技巧我今天碰巧特意查了相关的内容，并摘抄了一篇《提问的艺术》。

在实际工作中，你面对的人各式各样，有些人比较热情，你问什么他只要知道都会回答你，遇到这种人只能说你运气太好了；有些人比较平淡、严肃，而且很忙，你要问他们问题，你就必须好好思考一下问题的质量和表达是否清晰了，因为如果你连续问两三个比较低级（例如随便百度一下就能查到的）的问题，那你就会遭致他的反感了，更甚者会被教育；而面对那些高傲的人，问的艺术就要更高深了，因为一般情况下，他根本不鸟你，需要找机会、找时机甚至找借口问他们相关的问题，语言上更是马虎不得，否则一个小小的失误就会将好不容易争取来的提问机会给夭折了。

------跟着程序员走

本段内容个人理解为作者想表达测试人员与开发人员的紧密关系，两者有效的切合达到很高的工作效率。

不过毕竟作者只是表达了这个观点，其中具体实现还是有很多的难点存在，我大致阐述一下我在工作中遇到的问题：

1.      测试人员的反馈并不能被开发人员尽早地接受

鉴于开发任务紧，我一般都会要求开发人员完成一部分功能后就发布测试。当我在测试中发现问题后，通过缺陷管理工具或者将问题汇总以邮件方式发送给开发人员后，开发人员通常会将这些问题的解决排在完成其他功能之后，因而这个反馈环路中就会存在断层。

2.      毫无把握的等待不断地磨灭测试人员的积极性

由于缺陷提交后并不确定开发人员何时才会进行修改，主动权在开发人员的手中，长期的被动使得测试人员的激情被逐渐磨灭。

3.      重复地沟通、反复的跟催，浪费着测试人员大量的时间

不规范的公司，测试人员的处境往往都是很尴尬的，既要在规定的期限内保证测试的质量，又长期处于被动的位置，还不能跟开发人员闹僵，一个缺陷一个缺陷地解说，时不时地询问修改状况，常常又只能等待，最终大家的时间都在被浪费，更严重的是因此遗留在软件内的缺陷无法及时、有效地被发现。

上面的这些状况在长期得不到改善的情况下，作为测试人员就会有一种测试只是开发的附属的感觉，这必然会严重影响部门测试的进一步发展。

本人由于同时肩负着QC和SEPG成员的角色，因此一直希望通过制定有效、简明的机制改善以上状况，但由于部门的实际状况的制约，机制并不能很快被验证，只有一边做着持续改进的努力，一边等待着更好的时机的到来。（这里的时机指的外部环境的变化及主管对团队管理的重视）

----别指望任何人会理解测试，或理解测试员需要什么条件才能搞好测试

读到这则经验短文时我粗浅地认识到了几点：

1.      原来每一个团队所面临的问题都是类似的；

2.      原来我一直处于在一种理想的状态中，即期待着其它角色的理解（虽然还不完全赞同书中的论断）；

3.      文中有一个很形象的比喻：测试员的解释（向客户解释测试）就像是流感疫苗，有利于健康而又不那么痛苦，但是疫苗的作用会逐渐衰退，必须一遍又一遍地解释。

按照作者的说法，在读完之后认真思考后，我确实从中找到了3个关键点：

a． 测试员受管理层和程序员的决策的很大影响

从事测试工作以来，我都非常明确地知晓，测试员光靠自己是无法做好测试工作的，其它角色的配合状况从一定层面上注定这测试的成败。我之前非常希望部门可以建立一套完整的交互机制来减少甚至消除这方面的影响，但看来这个想法还是有很大的理想化成分，这过程中涉及的事项好像并非生硬的工具和制度所能够控制的。交互的机制和工具仅仅起到的也许只是个辅助的作用。

b．测试员可以向管理层和程序员提出要求帮助的方式来完成测试工作

这点在测试工作中有一定的体会，因为本身我就处于没有明确需求，只有个框架的情况下展开的测试，如对系统的了解、数据的来源等等，都需要程序员的帮助，之前我一直认为这不是个合理的方式，所以我一直没有深入地考虑过，但现在想来，这个过程也许在很多公司，很长一段时间内都可能会存在，所以有必要总结出一些东西。例如一份问题清单，以此向其它角色要求帮助，将这个过程条理化。

c． 测试员与客户解释的经验之谈

对于这个经验，目前还没有涉及，但也可以明确地感受到其中的工作艺术。