只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员

测试人员到底是什么样的人？

节选自《测试之美》 （原书名：Beautiful Testing ，作者：Tim Riley & Adam Goucher，译者：张 奭 等）

 

 

<!-- [if !supportEmptyParas]--><!-- [endif]-->

在 IT 世界里，测试人员的工作是极为特殊的。在商业世界里有多少份工作是付钱让你直言不讳的呢？ 当唯一的“桃子”显然有些坏掉的时候，测试人员不应该是拿着工资却告诉你一切正常。可以想象，你的项目组或 IT 部门的其他成员可能会有些不合时宜的乐观情绪或自相矛盾的评论意见。不过，测试人员拿了工资就是要告诉你他们所了解的一切事实，甚至有时候他们会直白地说你的小宝宝很丑，还给出一系列论据。

管理一群测试人员或者与他们共事，理解他们的思维是很有帮助的，这包括你得明白工作上什么事情才能让他们情绪高涨、兴奋异常。

那么测试人员到底是什么样的人呢？如果只列举少量的关键特质，那么首要的一点是测试人员有好奇心。 他们想弄清楚事物是怎么运行的；其次，他们喜欢动手实验 ，他们想知道尝试使用功能演示时不同的用户场景和实验会发生什么；再次，好的测试人员胆子比较大， 他们不害怕会破坏什么东西，不管你有多位高权重，他们也不害怕把发现的事实告诉你，他们更不害怕站出来据理力争，一定要把他们相信可能影响到产品成功的问题解决掉。测试人员聪明，善于分析，善于学习。事实上，他们总是在学习，他们的工作性质要求如此。技术总是在变化，他们接到的每个项目或多或少跟上一个项目不太一样。有时候他们有很好的文档，有时候没有很好的文档，有时候甚至没有成文的文档。他们必须问出正确的问题，研究正确的问题，把谜题的各个碎片联系在一起，然后得出正确的结论。测试人员一般不关心办公室政治，如果你发现一个测试人员特别精通此道，很有可能他的本职工作做得不是非常出色。 当你的工作是发现和报告问题，要想玩好政治游戏是很困难的。经常有人责备测试人员过于直接、粗鲁、团队合作精神不佳等。其实不然，很有可能责备他们的人不了解或者没能意识到项目组中测试人员的角色，他们的工作不允许他们隐瞒任何“不方便说”的信息。

上述这些是测试人员好的特质，还有其他一些不那么好的特质 ，但也是大部分测试人员整体个性中不可分割的一部分，尤其对那些测试经验丰富的人来说。测试人员容易不信任人 ，这是从实践经历中学来的，别人总是告诉他们模块 X 不需要测试，或代码 Y “没动过”，这种信息错的次数多到数也数不清了。所以就算你告诉测试人员草是绿的他们也要亲自过目才敢相信。测试人员是挑剔的，这个习惯也贯穿在他们生活的其他方面。他们的任务就是要发现和报告问题，这就是说如果你发给他们的电子邮件里有一个拼写错误，他们整个团队都会跳出来好心指出，甚至还有你（或者其他人）的其他错误。测试人员质疑一切，包括权威。一般来说想要用搞定其他部门的办公室政治手腕来欺骗或者算计测试部门可不容易，倒是告诉他们严酷的真相要来得好得多，这是唯一赢得他们尊重和信任的方法。

你可能认识一些并不具备前述特质的测试人员。不是测试团队里的每个人都算得上是测试人员，也不是每个具有测试人员头衔的人都算得上是个测试人员。 有的人满足于运行已有的测试，他们没有擅长分析、好奇和喜欢动手实验的天性，他们的胆子不太大，很容易被强势性格的人、位高权重的人或要去做新鲜事情的想法所动摇。他们可能因为害怕人们之后的反应而不报告缺陷；他们主要的顾虑是不要坏了大局，有的人过于“热衷”办公室政治和关注个人的计划和成功，以致失去了让他们在测试团队中与众不同的那些很有价值的特质。总的来说，根据你的部门大小不同，不同性格的人都可以对项目的成功贡献力量，但是花力气去识别和培养你部门里“真正的”测试人才是值得的。只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员。 当一个测试人员需要运行一大堆已有的测试用例时，容易心生厌烦，可能会尽快运行这些测试，只是想让它们从眼前消失。这意味着他们可能不会非常关注这些测试，当然也就不能像认真彻底的执行者一样找出某些问题。从好的另一方面来看，一个“真正的”测试人员一定会把这些已有测试看作自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方。 如果原来的分析实在很棒，那可能他们也找不出来太多可以更新充实的内容，进而增加了无聊指数。你会发现，如果每天的工作就是按部就班，如运行一大堆已有的手工测试用例，日复一日，那些真正富有创造力、勤勉的、聪明的测试人员的精气神儿、自主性和创造力都会消磨殆尽。为了你的测试人员士气着想，无疑需要让他们把手头工作交给愿意每天按部就班做事的人，或把手工测试自动化，或者不要让他们再做这些事情。他们想做点新的事情，想发现和报告缺陷，想贡献其他人无法贡献的力量。

很多测试人员觉得单调乏味而不屑运行回归测试用例，你会发现他们其实大部分都理解甚至同意回归测试的必要性，但这就像是面对一道人家已经解决的谜题，一点探索和寻宝的乐趣都没有了。大多数测试人员知道回归测试只能找到代码里的一小部分问题，他们更愿意去寻找新代码里潜伏的一大堆问题，这完全就是探索和寻宝的乐趣之旅。

那么在态度方面，难道不应该团队协作吗？千真万确，你的测试人员也愿意扮演好团队成员角色，他们是想帮忙作贡献的，他们很希望自己得到欣赏，但是他们关注的东西让项目组其他成员难以接受和欣赏他们的贡献。他们的幽默甚至增加了让他们融入团队的难度。更糟的是，如果你在一个不关注质量的公司工作，并不认同或不解决测试人员辛辛苦苦发现的问题，测试团队会认为这是对他们以及他们的工作缺乏尊重。如果你不给予测试人员他们应得的尊重，很快就会让他们士气低落，然后你就很难留住具有本土市场上热门技能的人才。

总的来说，现在整个测试业界已经相对成熟、文明有礼了，测试人员变得更能与人“和睦共事”。最有经验的测试人员会同情地拍拍你的肩膀说：地球人都知道事情不仅仅是发现问题那么简单。他们也会充分理解、全力支持你的决定：问题 A 、 B 、 C 可以不解决了，不会有人就此激动万分大发雷霆的。实际上，拥有多年工作经验的测试人员会说出你所喜闻乐见的意见，因为他们从这家公司的项目经验中学乖了，知道这样会给他们（当然也就是给你的部门）带来最好的质量结果。但是需要记住，他们之所以肯牺牲问题 A 、 B 、 C ，很可能是为了说服你解决更严重的问题 D 和 E 。大多数测试人员私底下希望你解决他们找到的所有问题，测试人员很明显会偏向于把问题都解决掉，他们看见出错的东西，就想改进它们。 想想吧，你真的希望测试人员不这么想吗？

一般来说，经验丰富的测试团队能用漂亮的包装纸（词汇）和丝带（对于问题的理解）来呈现一个缺陷，过了好一阵你才会意识到自己收到的是一大堆恶心的牛粪。他们也不过是转赠而已，是你先给了他们这样的东西，不知何故你给他们的时候没有发现这玩意儿真的是相当臭。他们用礼貌的政客语言跟你讲话，这跟在你耳朵听不到的场合（如在牧场跟其他牛仔侃起大山时）说的话可是完全不同的。他们在痛苦的经历中学到，与其共事的其他领域的“家伙”是不能真正欣赏他们这种幽默和乐趣的：在地里系统全面地搜寻牛粪，然后用系着大红蝴蝶结的漂亮彩盒子装起来送给项目组……

搜寻软件毛病（缺陷）很像寻宝之旅。缺陷通常是藏起来的，要找到它们需要同时具有逻辑、技术和直觉（或者说运气）。很多测试人员都很喜欢谜题，这并非偶然。他们就喜欢搜寻和发现东西。寻宝令人兴奋，发现一个错误（或者说答案）是终极动力。当测试人员发现缺陷之日，就是他们赚取酬劳之时。在他们看来，那意味着最终用户不会发现的问题多了一个，开发团队改进产品的机会多了一个，公司的风险因素少了一个。找到一个缺陷就是一个值得欢呼雀跃的意外收获。 开发团队或管理层认为是令人不爽、厌恶、沮丧的没解决的问题，对测试人员来说却是美妙的事物，是埋藏的宝藏，是达布隆金币。

不同的测试人员为搜寻缺陷做着不同方面的准备。他们的准备工作取决于你的环境和研发方法，一些准备工作源自个人偏好，他们可能提前开始写测试用例，也可能从一个笔记列表入手。但是不管技术方面怎么样，有些事情是各种技术都共通的。

他们要阅读一切帮助了解测试目标的资料，要问问题——很多很多的问题，一直问到他们满意觉得足够了解该应用程序为止，然后他们要决定如何最好地进行测试并制定一个计划。这个计划也许很正规，也许只在他们的脑子里，但大多数测试人员在开始测试之前就知道他们想要检查什么，在开始实验的时候也大致知道系统应该是什么样以及如何工作。

这就是技术、培训、经验发挥作用的时候了。一个受过培训、经验丰富的测试人员总是比缺乏培训、经验不足的人找到更多的错误。这与智力无关，只是缺乏指导和学习。 这也不是说新人就会一无所获，他们也能发现一些东西，但是经验丰富的测试人员知道哪里容易发现缺陷，什么容易出问题，他们还从经验中学到在类似的情况下哪种技术曾成功地帮他们发现缺陷。一个测试人员是否受过“正规的”培训（边界分析等），或敏捷技术培训（启发式、游历式等），或者两者都学过，并不那么要紧。一旦测试人员学会阅读字里行间暗藏的玄机，观察显而易见之外的事物，询问一针见血的问题，以及眼界的扩展，你就成为了一名真正的测试强人，通过继续学习和掌握新的工具，你的力量将随着职业生涯不断增强。